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ABSTRACT 

Conversion between graphical representations and structural text-based 
representations of business process. A set of identifiable features and associated pattern 
mappings is defined. Graphical representations are converted by identifying features and 
referring to associated pattern mappings to define an equivalent structural text-based 
representation. Appropriate structural text-based representations are converted by 
determining features for the graphical representations based on the associated pattern 
mappings that are determined to conespond to the structural text-based representations. 
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SYSTEM AND METHOD FOR CONVERSION BETWEEN GRAPH-BASED 
REPRESENTATIONS AND STRUCTURAL TEXT-BASED REPRESENTATIONS 

OF BUSINESS PROCESSES 

Field of the Invention 

5 The present invention relates generally to computer systems and more specifically 

to a system and method for conversion between graph-based representations and structural 
text-based business process representations. 

BackfiTound of the h^vention 

A business process includes a defined set of actions taken in the course of 

10 conducting business. Throu^ the use of computer systems, business processes can be 

automated. An automated business process typically requires input and generates output. A 
business process may be a single task or a complicated procedure such as a procedure for 
building a product. An example of a more complicated computer-implemented business 
process is a business transaction against a database for the purchase of goods on the Internet 

IS The term ^l^usiness process" also includes other processes that are related to a business 
context in a broad sense - for example a process used to manage donor lists for a charity is 
referred to as a '"business*' process although it relates to a charitable activity and not a 
business activity as narrowly defined. For all business processes, but in particular for 
automated business processes, it is potentially advantageous to document the processes using 

20 a computer-implemented representation. Often business processes are graphically represented 
in a computer-implemented system using a visual representation. 

Compute software such as the WebSphere™ Studio Application Developer 
Integration Edition (WSADDB) process tool distributed by IBM Corporation allows users to 
visually represent a business process as a graph having features defined by node, terminal and 
25 connection elements. Connection elements connect nodes as in a directed graph and provide a 
flow that is apparent in die visual representation and which is intended to represent the 
relationships between activities in business processes. In a graphical representation that is 
used to control a business process, control over the process is transferred from node to node 
as the connection elements are followed. 
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Alternatively, business processes may be represented in a computer system 
textually using a structural computer language, such as Business Process Execution Language 
for Web Services (BPEL4WS). BPEL4WS is used to describe business processes and is 
based on Extensible Markup Language (XML) specifications* BPEL4WS allows for text- 
5 based business process lepresentations having a structure of hierarchical nested elements. 

It is often desirable to convert a representation of a business process from a 
graphical to a struaural text-based representation, or vice versa. However, sudi conversions 
present difficulties. For example, different prograimners charged with the task of converting 
a graphical representation of a business process to a text-based representation may apply 

10 different approaches to determine equivalent representations for graphical representations 
where control is transferred from one clement to the next Consequently, different structural 
text-based representations of the same graphical representation of a business process may be 
dissimilar, particularly where the graphical representation of the business process is marked 
by sophisticated flow logic. Despite the convenience of using a graphical representation to 

15 describe a business process, it becomes less desirable if it is intended to be shared among 
several users who may convert the features of the graphical representation differently. 
Different conversions may use the structural elements available in the text-based 
representations to varying degrees. Typically, the use of stmctural elements in the text-based 
representation aids in readability of the representation. 

20 Furthermore^ in some cases structural text-based rqireseDtations derived fiom a 

graphical representation of a business process may be converted back to a graphical form. If 
the original conversion to the text-based representation is not carried out in a manner that 
preserves the semantics of the graphical rq)resentation as much as possible, after the re- 
conversion to the grs^hical representation form the business processes rq[iiesented by the 

25 representations (the original graphical representation and the re-converted version derived 
from the text-based representation) may not be identical. This lack of consistency may 
decrease the accuracy of computer-implemented representations of the business process. 

Various components or characteristics of the business process may be expressed in 

more than one computer language or format, such as XML and Java. While it is known to 

30 provide a process for mapping an XML document to Java, as suggested in the white paper 

^ published by CoUaxa, CoUaxa WSOS 2.0: An Introduction, the prior art does not disclose a 
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method of moping business process features from a graphical representation to a structural, 
text-based representation that preserves the flow logic of the business process structure. 

Accordingly, it is desirable to convert graphical representations of a business 
process to a structural, text-based computer language representation, where the logic and 
5 features are converted in a correct and consistent manner and where the conversion from the 
text-based to graphical representation is also supported. 

Summary of the Invention 

Hie present invration provides a system and method for converting from 
graphical representations to structural text-based language representations of business 

10 processes. In a conversion carried out in accordance with one aspect of the invention, a 
graphical rq)resentation is analyzed in comparison with a set of defined features. An 
associated pattern mapping is defined for each feature in the set, and the appropriate mapping 
is used in the conversion to a structural text-based representation. The present invention also 
provides a system and method for converting from stmctural text-based representations of 

15 business processes to gnqohical representations. 

In the preferred embodiment, an aspect of the present invention can be used to 
export a business process built using the WSADIE process tool and having features 
corresponding to a set of generally accepted features to a BPEL4WS representation, and can 
also be used to import a business process represented in BPEL4WS having features 
20 corresponding to a defined set of patterns for conversion into the WSADIE process tool 

An advantage of an aspect of the present invention is the ability to obtain 
consistent and repeatable conversions from graphical representations to strucmral text-based 
representations of business processes. The structural text-based representations resulting 
from such conv^ons are also cq>able of re-conversion to equivalent graphical 
25 rq}reseatations. 

Another advantage of an aspect of the present invention is die readability of the 
exported strucmral text-based language representation resulting from the use of structural 
. elements promoted in the conversion to a text-based representation carried out in accordance 
with the invention. 
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Accordingly, an aspect of the invention provides a computer program product for 
converting between gr^hical and structural text-based representations of business processes, 
having program code for storing and maintaining a set of features identifiable in graphical 
business process representations, each feature in the set of features having an associated 
5 pattern mapping defined relative to structural text-based rq)resratations; identifying portions 
of an initial gr^hical representation as matching features in the set of features; generating 
structural text-based representations of the identified portions of the initial graphical 
representation by applying ttie pattern mappings associated with the matching features to the 
identified portions of the graph-based representation; identifying portions of an initial 

10 structural text-based representation of a business process as corresponding to pattern 
mappings associated with features in the set of features; and generating graphical 
representations of the identified portions of the initial structural text-based representation by 
reference to the features associated with the pattern mappings corresponding to the identified 
portions of the initial structural text-based representation. An aspect of the invention ftirth^ 

15 provides a set of identifiable features stored and maintsuned in the program code consisting of 
features selected from; synchronous and asynchronous processes, request/response activities, 
one-way activities, empty nodes, blocks, iterations, receive events, compensation, correlation, 
variables, fault handling and transition conditions. 

A further aspect of the invention provides a set of identifiable features and 
20 associated pattern mappings consisting of feature and pattern mapping pairs selected from die 
following set of pairs: 

i. feature: synchronous/asynchronous processes; pattern mapping: a 
synchronous process representation comprises a <receiv& activity as 
its input interface, and a <reply> activity as its output interface; an 

25 asyndironous process representation comprises a <teceive> activity as 

its input int^aoe, and an <invoke> activity as its output interface; 

ii. feature: request/response activity; pattern mapping: an<invoke> 
activity with attributes inputContainer and outputContainer to specify 
inputandoutputcontainersassigned to the activity; 
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iii. feature: one-way activity; pattern mapping: an <invoke> activity, with 
attribute inputContainer and no outputContainer; 

iv. feature: empty node; pattern mapping: an <empty> activity defined by 
a naming convention including node name; 

5 v: feature: block; pattern mapping: a <scope> activity with two <empty> 

activities nested within the <scope> activity to represent the input and 
output nodes in the block; 

vi, feature: iteration; pattern mapping: a <while> activity having an 

attribute condition equivalent to the loop condition in the loop node of 
10 the iteration; two <empty> activities nested within the <while> activity 

to represent input and output nodes in the loop body of the iteration; 

vii. feature: receive event; pattern mapping: a <pick> activity containing 
<onMessage> structures to define events accepted by the <pick> 
activity, corresponding to events defined in the receive event; 

15 viii. feature: compensation; pattern mapping: a <oompensationHandler> 

structure comprising an activity witfdn the structure to compensate an 
execution failure; 

ix. feature: correlation; pattern mapping: a <correlation> element having a 
correlation ID defined and referenced by a <correlationSet> element; 
20 the <correlation> element being nested within a <receive> activity 

representing an input node, and within all <pick> activities 
corresponding to one or more receive event nodes; 

X. feature: variables; pattern mapping: containers; 

xi. feature: fault handling; pattern mapping: a <catch> structure containing 
25 elements in a fault path if the fault is only thrown once; whm the fault 

is capable of being rq)eatedly cau^t and thrown then 



(a) if thrown internally: a <thtow> activity; or 
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(b) if thrown externally: a <reply> activity; and 

xiL feature: transition condition; pattern mapping: an attribute in a 
<source> element of a <link> element representing the transition. 

A further aspect of the invention provides an import and export U)ol for exporting 
S from graphical represratations of business processes to structural t^t-based representations 
and for importing from structural text-based representations of business processes to 
graphical representations, comprising storage and maintenance code for implementing the 
storage and maintenance of a set of features identifiable in graphical business process 
representations* each feature in the set of features having an associated pattern mapping 

10 defined relative to structural text-based representations, graph identification code for 

identifying portions of an initial graphical representation as matdiing features in the set of 
featui^ export generation code for generating structural text-based representations of the 
identified portions of the initial graphical representation by £q)plying the patteni mappings 
associated with the matching features to the identified portions of the graph-based 

15 representation, import identification code for identifying portions of an initial structural text- 
based representation of a business process as corresponding to pattern mappings associated 
with features in the set of features, and import generation code for generating graphical 
representations of the identified portions of the initial strucmral text-based representation by 
reference to the features associated with the pattern mappings corresponding to the identified 

20 portions of the initial structural text-based representation. An aspect of the invention fiirth^ 
provides that this import and export tool uses a set of identifiable features and associated 
pattern mappings consisting of feature and pattern mapping pairs selected from set of pairs 
itemized above. 

Another aspect of the invention provides a computer program product for 

25 converting from a graphical to a structural text-based rq}resentation of busine^ss processes 

with code for storing and maintaining a set of features identifiable in graphical business 

process representations, each feature in the set of features having an associated pattern 

mapping defined relative to structural text-based representations, identifying portions of an 

initial graphical representation as matching features in the set of features, and generating 

30 structural text-based representations of the identified portions of the initial graphical 

representation by applying the pattern mappings associated with the matching features to the 
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identified portions of the graph-based representation. A further aspect of the invention 
provides code for extracting properties from graphical elements in the identified portions of 
the initial graph-based representation and defining corresponding attributes for elements in 
the generated structural text based representations. Still a further aspect provides code using 
5 a set of identifiable features selected from the list of features provided above, and a set of 
identifiable features and associated pattern mappings selected from the set of pairs of features 
and mappings itemized above. 

A further aspect of the invention provides an export tool for exporting from 
graphical representations of business processes to structural text-based representations* 

10 consisting of storage and maintenance code for implementing the storage and maintenance of 
a set of features identifiable in graphical business process representations, each feature in the 
set of features having an associated pattern mapping defined relative to structural text-based 
representations, graph identification code for identifying portions of an initial graphical 
representation as matching features in the set of features, and export generation code for 

15 generating structural text-based representations of the identified portions of the initial 
graphical representation by applying the pattern mappings associated with the matching 
features to the identified portions of the graph-based representation, with a set of identifiable 
features selected from: synchronous and asynchronous processes, request/response activities, 
one-way activities, empty nodes, blocks, iterations, receive events, compensation, correlation, 

20 variables, fault handling and transition conditions. Still a further aspect of the invention 
provides an export tool using a set of identifiable features and associated pattern mappings 
from the set of pairs itemized above. 

A further aspect of the mvention provides an import tool for importing from 
structural text-based representations of business processes to gr^hical r^resentations, 

25 comprising storage and maintenance code for implementing the storage and maintenance of a 
set of features identifiable in graphical business process representations, each feature in the 
set of features having an associated pattern mapping defined relative to structural text-based 
representations, import identification code for identifying portions of an initial structural text- 
based representation of a business process as corresponding to pattern mappings associated 

30 with features in the set of features, and import generation code for generating graphical 

rq)resentations of the identified portions of the initial structural text-based represmtation by 
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reference to the features associated with the pattern mappings corresponding to the identified 
portions of tfie initial structural text-based representation. An aspect of the invention further 
provides an import tool using a set of identifiable features and associated pattern mappings 
consisting of feature and pattern mapping pairs selected from set of pairs itemized above. 

5 An aspect of the invention further provides that the code includes means for 

converting Java code referenced in the initial graphical representation, specifically Java 
snippet nodes, and Java assignment and condition expressions, to XPath code in the generated 
structural text-based representation. 

A further aspect of the invention provides that tfie initial graphical representation 
10 is compatible with the Web Sphere™ Studio Application Developer btcgration Edition 
platform and that the ^nerated structural text-based representation is compatible with the 
Business Process Execution Language for Web Services platform. 

An aspect of the invention provides a method for converting from graphical to 
structural text-based representations of business processes with the steps of: defining and 

15 maintaining a data representation of a set of features identifiable in graphical business process 
representations, each feature in the set of features having an associated pattern mapping 
defined relative to structural text-based representations, identifying portions of an initial 
graphical representation matching features in the set of features, and generating structural 
text-based representations of the identified portions of the initial graphical representation by 

20 applying the pattern mappings associated with the matching features to the identified portions 
of the graph-based representation, where the set of identifiable features is selected from: 
synchronous and asynchronous processes, request/response activities, one-way activities, 
empty nodes, blocks, iterations, receive events, compensation, correlation, variables, fault 
handling and transition conditions. A furtfa^ aspect of the invention provides a method for 

25 converting from graphical to structural text-based representations of business processes where 
the set of identifiable features and associated pattem mappings is selected from the set of 
pairs itemized above. Still a further aspect of the invention provides a conversion method in 
which the step of generating structural text-based representations of the identified portions of 
the initial graph-based representation further comprises the steps of converting Java code 

30 referenced in the initial graphical representation, specifically Java snippet nodes and Java 

assignment and condition expressions, to XPath code in the generated structural text-based 
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representation, and the initial graphica] representation is compatible with the Web Spheie^^ 
Studio Application Developer Integration Edition platform and the generated structural text- 
based representation is compatible with the Business Process Execution Language for Web 
Services platform. In a further aspect of the invention, a computer program product is 
provided for accomplishing the above method, either on a recordable data storage medium or 
in a modulated carrier signal transmitted over a network such as the btemet. 

Brief Description of the Drawings 

In drawings which illustrate by way of example only a preferred embodiment of 
the invention. 

Figure 1 is a block diagram illustrating a high level description of the preferred 
embodiment. 

Figure 2a illustrates a graphical representation of a business process that shows a 
simple synchronous process. 

Figure 2b illustrates a graphical rq»pesentation of a business process that shows a 
simple asynchronous process. 

Figure 3 illustrates a graphical representation of a business process that shows a 
simple process having an empty node and a Java snippet node. 

Figure 4a illustrates a graphical representation of a business process that shows the 
contents of the body of a sinq)le block. 

Figure 4b illustrates a gr^Mcal representation of a business process that shows a 
block having the block body shown in figure 4a. 

Figure 5a illustrates a graphical representation of a business process that shows the 
contents of the body of a simple loop. 

Figure Sb illustrates a graphical representation of a business process that shows a 
loop having the loop body shown in figure Sa. 



Figure 6 illustrates a graphical representation of a business process that shows a 
pick process. 
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Figure 7 illustrates a graphical representation of a business process that shows a 
simple process having a service node that has a compensation service. 

Figure 8 illustrates a graphical representation of a business process that shows a 
simple process having a receive event node. 

5 Figure 9 illustrates a gmphical representation of a business process with a fault 

terminal. 

Figure 10 illustrates a graphical representation of a block body in a business 
process having a fault terminal. 

Figure 1 1 illustrates a graphical representation of a business process that shows a 
10 process having a block node» the body of the block being as shown in Figure 10. 

Figure 12 illustrates a graphical representation of a loop body in a business 
process having a fault terminal. 

Figure 13 illustrates a graphical representation of a business process that shows a 
process having a loop node, the body of the loop being as shown in Figure 12. 

15 Figure 14 illustrates a graphical representation of a business process that shows a 

simple process that contains multiple control connections with conditions set on the 
connections. 

Figure 15 illustrates a graphical representation of a business process that shows a 
process having a node with a fault terminal where the fault terminal has outgoing control 
20 connections to two different nodes. 

Figure 16 is a gr^hical representation of a business process that contains multiple 
Java snippet nodes with assignment code set on the nodes. 

Figure 17 illustrates a graphical r^resentation of a business process that has 
multiple links with conditions set on the links. 

25 Detailed Description of the Invention 
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The preferred embodiment is described with reference to graphical representations 
of business processes defined using the WSADE version 5 process tool and structural text- 
based representations using the BPEL4WS business process language. It will be understood 
by those skilled in the art that the system and method of the preferred embodiment may be 
5 carried out with reference to representations made using other tools for creating graphical 
representations of business processes or other business process languages that similarly define 
the structure of a business process in a hierarchy of nested elements. 

Figure 1 shows, in a block diagram, high-level components in the system of the 
preferred embodiment. Graph-based representation 2 is shown as being either input to, or 

10 output from, conversion tool 3. Similarly, text-based representation 4 is shown as being 
alternatively input to, or output from, conversion tool 3. Conversion tool 3 is shown 
referencing set of features 5 and pattern mappings 6. Each of these are representations of 
feature information and pattern mapping information and which may be implemented in 
different ways for use by conversion tool 3. Set of features 5 has associated pattern mappings 

15 6 and the interrelationship between the two representations is shown by the arrow between the 
two blocks in Figure 1. As is described in more detail below, conversion tool 3 accesses set 
of features 5 and associated pattern mappings 6, to carry out conversions between graph- 
based representation 2 and structural text-based representation 4. 

In the preferred embodiment, the set of identifiable features that may be mapped 
20 between the graphical and structural text-based business process representations (set of 
features 5 in Figure 1), consist of the following (for ease of reference, conventional 
BPEL4WS terminology is used to describe the features): 



(1) 


synchronous and asynchronous processes; 


(2) 


request/response activities; 


(3) 


one-way activities; 


(4) 


empty nodes; 


(5) 


blocks; 



(6) iterations; 
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(7) receive event (ability to wait for events to select a path of execution based on 
the event received); 

(8) compensation; 

(9) correlation; 

(10) variables; 

(1 1) fault handling; and 

(12) transition conditions. 

A conversion from a representation of one type to that of the other may involve 
simple one-to-one mappings, or more complex mapping operations. When converting from a 
graphical representation to a structural text-based representation, elements in the graphical 
representation are mapped to corresponding elements in the structural text-based 
representation. Properties of the graphical element are extracted and saved as attributes of its 
corresponding element in the structural text-based representation. In the description below, 
mapping from a graphical representation to a structural text-based representation (from 
graphical representation 2 to structural text-based representation 5) is referred to as 
"exporting" a process. An "exporter" is preferably a software tool that exports a process 
according to the preferred embodiment (in the example of Figure 1, conversion tool 3 is 
capable of acting as an exporter). 

When converting from a structural text-based representation to a graphical 
representation, elements in the structural text-based representation, except for structural 
features that are used to define sequential or concurrent flow or synchronization in the 
business process, are mapped to appropriate node elements according to the pattern mq)pings 
for conversion. Attributes of elements in the structural text-based representation are converted 
to the appropriate properties of the corresponding graphical node elements. The layout of the 
graphical representation can be constructed by examining the structural elements in the 
structural text-based representation. In the description below, mapping from a structural text- 
based representation to a graphical representation is referred to as 'Importing" a process. An 
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"in^)ortei^' is preferably a software tool that imports a process according to the preferred 
embodiment (in the simple example of Figure I, conversion tool 3 functions as both an 
importer and an exporter). 

As will be apparent from the description set out below, business process graphs 
5 are defined using graphical elements including node, terminal and connection elements. The 
method and system of the preferred embodiment is capable of converting such graphs to an 
appropriate structural text-based representation. The method and system may also be used to 
convert from certain structural text-based representations to a graphical representation, where 
such text-based representations meet criteria set out in more detail below. 

10 According to the prefetred embodiment, an exporter process first identifies the 

features of the business process represented in the graphical representation to be converted 
In the preferred embodiment, the set of features listed above is used (set of features 5 in 
Figure 1) and the exporter process identifies the properties associated with each identified 
feature in the graphical representation. The exporter is able to access a set of pattern 

15 mappings corresponding to the set of possible identified features. The pattern mappings 

correlate the graphical representation of each feature to a structural text-based representation. 

After identification, the portions of the graphical representation having features in 
the feature set are converted to coitesponding structural text-based representations using the 
appropriate pattern mappings, while preserving the associated properties of each portion of 
20 the graphical representation. The flow logic of the business process may then be constructed 
in the structural text-based representation by linking the text-based rqpresentations in a 
manner that will be understood by those skilled in die relevant art. For example, to connect 
text-based representations corresponding to nodes in the graph being converted, the 
BPEL4WS link construct may be used. 

Using the approach of the preferred embodiment, a complete structural text-based 
representation equivalent to the gr^hical representation of the business process may be built. 
According to the preferred embodiment, the different identifiable features referred to above, 
and a description of their associated pattern mappings, are set out below, with simple 
examples provided by way of illustration. 



25 
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f 1) Synchronous and Asynchronous Processes : In graphical representations 
defined using the WSADIE process tool of the preferred embodiment, a synchronous process 
is modelled by a request/response interface. A caller invokes this operation to run the process. 
The result of the process is then returned to the caller immediately via this request/response 
5 operation. 

When a synchronous process feature is identified in a representation in the graph- 
based process tool, access is made to the associated pattern mapping. The pattern mapping 
includes a text-based (BPEL4WS) representation having <receive> and <repiy> activities 
as its interface. The <receive> activity represents the input interface of the synchronous 
10 process in the graphical representation. The <reply> activity represents the output interface 
of the synchronous process. In the case of a synchronous process, the <repiy> activity 
usually returns the result shortly after the process is invoked. 

Hgure 2a illustrates a simple synchronous process displayed in the graph-based 
process tool of the preferred embodiment. The synchronous process 10 defined has an input 
15 node 12, an output node 14 and a fault node 16. 

The example synchronous process of Figure 2a is mapped to a structural text- 
based representation in accordance with the pattern mapping referred to above. For the 
exan^le given, an example equivalent text-based {BPEL4WS) representation that may be 
generated by applying the pattern mapping is the following segment: 

20 <I-- from BPEL4WS file — > 
<sequence> 

<receive containerss" input " createlnstance=:"yes" operation="VWOp" 
1 portType=''ns2 tWVPortType" /> 

25 <flow> 

<reply container="vWFaultMsg'' faultName="ns2 iWVPaultMsg" 
name- " Fault " operation^ " VWOp" portType= "ns2 : WVPortType " / > 

<reply container= • output " operation="WVOp" 
portType= •'ns2 : WVPortType " /> 

30 </flow> 
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</sequence> 

In accordance with the preferred embodiment and the pattern mapping defined as set out 
above, the <receive> activity in the BPEL4WS fragment represents the input node 12 from 
the graph-based representation of Figure 2a. In the preferred embodiment, the <receive> 
5 activity preferably has operation and portivpe attributes which identify the interface of the 
process. Further, the output node 14 is represented by a <reply> activity without a 
faultName attribute. The <reply> with f aultName="ns2 : vWFaultMsg" represents the fault 
node 16. 

With respect to the reverse conversion, an importer interprets <r€ply> activities in the text- 
10 based representation as output nodes unless there is a faultName attribute specified. Hie 
faultName attribute corresponds to the qualified message type of the container set on the 
fault node. The name attribute corresponds to the name of the node. 

Exporting a process to BPEL4WS requires variables to be assigned to input and 
output nodes as this corresponds with the BPEL4WS specification requirement of requiring 
15 containers defined and referenced for <receive> and <repiy> activities. On export, the 

createinstance attribute is always set to yes on the <receive> activity, as this starts off the 
process. 

As the above explanation and example indicate, where thete is an identification of 
a feature in a graph-based representation that is synchronous, a BPEL4WS text-based 
20 representation may be determined by using the pattern mapping that is defined for such a 
synchronous process feature. 

The same type of approach may be applied for graph-based representations that 
include an asynchronous process. An asjTichronous process is generally a long-running 
process. In the graphical process tool, such an asynchronous process is modelled by a one- 
25 way interface: a caller process invokes the asynchronous process through this one-way 

interface. The result is returned to the caller process by invoking a callback operation, which 
is another one-way operation. The input interface is represented by an input node in the 
process tool. The output interface is represented by an output node in the process tool. 
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The pattern mapping for an asynchronous process in the graphical process tool is 
provided by a BPEL4WS process with <receive> and <invoke> activities as its interface. 
The <receive> activity represents the input interface of the asynchronous process. The 
<invoke> activity represents the output interface of the asynchronous process. This activity 
5 returns the result by invoking a service provided by the caller, which is equivalent to die 
property of an asynchronous process built with the process tool. 

Figure 2b illustrates a simple example asynchronous process as displayed in the 
graph-based process tool. For the asynchronous process 20, the input node 22, the output 
node 24 and the fault node 26 each use a different one-way interface. 

10 The asynchronous process shown in Figure 2b may be converted to a structural 

text-based representation, using the pattern mapping described above, in accordance with the 
following example segment: 

<!-- from BPEL4WS file — > 
<sequence> 

15 <receive container=" input" createlnstance="yes" operations "YYYOp'* 

port Types: >» ns2 : YYYPortType " / > 

<f low> 

< invoke inputContainer= " output " name= " 0utput_0utput 1 " 
operations "ZZZOneWay Op" portType=''ns4 : ZZZPortType" /> 

20 < invoke inputContainer="eEEInputMsg'' naine="Fault_Faultl" 

operations "EEEOp" portType="ns3 :EEEPortType"/> 

</f low> 

</sequenc€> 

In the equivalent BPEL4WS representation, a <receive> activity represents the input node 
25 22. An <invoke> activity with the following naming convention represents an output node 
such as output node 24 in Figure 2b: 

name = "Output^" + [Name of Output Node] 
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where the name prefixed by "output." identifies the <invoke> as an output 

node. 

An <invoke> activity with the following naming convention represents a fault 
node such as the fault node 26: 

name = "Fault." + [Name of Fault Node] 

where the name prefixed by -Fault." identifies the <invoke> as a fault node. 

The operation and portType attributes of an <invoke> activity identify the 
operation that will be invoked by the process, in order to return results to the appropriate 
process instance. 

In the graphical representation, whether a prx)cess is synchronous or asynchronous 
cannot be ascertained solely from viewing the graphical representation. A property tiiat is 
associated with a graphical representation component in the graphical representation indicates 
whether a given process is synchronous or asynchronous. Hence the term "graphical 
representation" is used to describe the combination of graphical representation components 
and the properties associated with graphical representation components. 

(2) Request/Response Activities : Request/Sresponse activities are identifiable 
features in graphical representations of business processes. In general, request/response 
activities are represented by service nodes in the graphical representations of the preferred 
embodiment. These service nodes take input from, and return an output to, the process. Both 
the input and output are variables in the process. Variables must be assigned to the service 
node to specify the input and output parameters. 

When a request/response activity feature is identified, the exporter accesses the 
corresponding pattern mapping. In the preferred embodiment, the pattern m^^ping defines 
the corresponding BPEL4WS element to be an <invoke> activity, which is used to invoke an 
operation. An <invoke> activity has attributes inputcontainer and outputcontainer to 
specify the input and output containers assigned to this activity. 

An example of BPEL4WS for an <invoke> with a request-response operation is: 

<i— from BPEL4WS file — > 
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< invoke inputContainer= "rRRInputl^sg" naine= " RRROp " operat ion= " RRROp " 
outputContainer= " rRROutputMsg ■ por tType= "ns3 : RRRPortType " /> 

The mapping involves converting the request/response activity to an <iiivoke> activity. The 
attributes inputcontainer and cutputcontainer reference the contaners used by this 
5 <invoke> activity. 

Where request-response operations on service nodes are represented in 
BPEL4WS, the name attribute of the <invoke> activity is the name of the service node. The 
inputcontainer and outputcontainer attributes are mapped to containers created for the 
variables assigned to the input and output terminals of the service node. The portiype and 
10 operation attributes correspond to the port type and operation set on the service node. These 
attributes define which operation the process will invoke. 

(3) One-way Activities : Like request/response activities, one-way activities arc 
represented by service nodes in the process tool. However, one-way activities only take an 
input parameter and return nothing to the process. Users must only assign an input variable to 
15 the service node representing a one-way operation. 

When a one-way activity is identified, the exporter accesses the corresponding 
pattern mapping. In the preferred embodiment, the appropriate pattern mapping is an 
<invoke> activity. 

An example of BPEL4WS for < invoke > activities specifying one-way operations 

20 is: 

<!-" from BPEL4WS file — > 

< invoke inp\itContainer= "yVYInputMsg" naine="YYY0p" operations "YYYQp" 
portType="ns3 : YYYPortType" /> 

The mapping is similar to mapping of request/response activity; however, there is no attribute 
25 outputcontainer because no output variable is assigned to the corresponding service node. 

Where one-way operations on service nodes are represented in BPEL4WS, the 

name attribute of the <invoke> activity is the name of the service node. The 

inputcontainer attribute is mapped to a container created for the variable assigned to the 

input of the service node. There is no outputcontainer attribute, since one-way operation 
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does not return anything as output. The portType and operation attributes correspond to the 
port type and operation set on the service node. These attributes define which operation the 
process will invoke. 

(4) Empty Nodes: An empty node does not correspond to any operation 
execution, but it provides a visual joint point It also serves other purposes as detailed in the 
sections dealing with blocks and loops, below. 

Hguie 3 illustrates a grairiucal rq)iesentation of a simple process containing an 
empty node 32 (Figure 3 also shows Java snippet node 34, described in more detail below). 

When an empty node is identified in a graphical representation, the exporter maps 
the feature to a pattern mapping with an <eniptY> activity. In the preferred embodiment, the 
activity uses the following naming convention: 

name « "En©ty_" + [Name of node] 

With respect to conversions from text-based to graphical representations, in the 
preferred embodiment, only <ems>ty> activities with this naming convention are imported as 
empty nodes. Conversely, empty nodes are exported with this naming convention. In the 
preferred embodiment, <eii5>ty> activities that do not correspond to empty nodes in a 
graphical representation are used as placeholders in some BPEL4WS mappings. Similarly, 
these placeholder <empty> activities are defined using specific naming conventions. 

(5) Blocks : A block node collects elements together as a distinct subset of the 
process. In the process tool, the block body must contain both input and output nodes as the 
start and end of the flow in the block node. 

When a block node is identified, the pattern mapping applied by the exporter 
groups a subset of connected acti\'ities together as one distinct portion in the business 
process, which may be interpreted as a sub-routine. In the preferred embodiment, the 
mapping includes a <scope> activity. 

Figure 4a illustrates the contents of the body of a simple block, as it would be 
displayed in the process tool. Figure 4b illustrates a block in a process in this example, the 
block having the block body shown in the figure 4a. 
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The block shown in Figure 4a may be mapped to a structural text-based 
representation in accordance with the following segment: 

<l— from BPEL4WS file --> 

<scope containerAccessSerializable="no" name=" Block" > 

S <sequence> 

<einp ty name* ■ Input^I nput 1 " / > 
<eingpty name= " Ou tput„0utput 1 " / > 

</sequence> 

</sccpe> 

10 The process shown in Figure 4b may be mapped to a structural text-based 

representation in accordance with the following segment: 

<!— from BPEL4WS file — > 
<sequ€iice> 

<receive container^" input" creat€lnstance=''yes" operation»''RRRCp" 
1 5 por t Type= " ns2 ; RRRPor tType " / > 

<scope containerAccessSerializable="no'' name=" Block" > 

<sequence> 

<en^ty name= " Input_Inputl " / > 
<ern(pty name= " 0utput_0utput 1 V > 

20 </sequence> 

</scope> 

<reply containers "output" operations "RRROp" 
portType= " ns2 : RRRPorf^XVpe " / > 

</sequence> 

25 Hence the mapping involves converting a block node to a <scope> acdvi^'. All elements in 
the block body are converted according to the mappings described in the preferred 
embodiment The resulting structures are nested within the <scope> activity. To make both 
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representations equivalent, two <enrpty> activities are nested within the <scope> activity to 
represent the mandatory input and output nodes in the block body. 

A <scope> activity represents a block node such as the block node 52 and has the 
following pattern: 

5 name = [Name of the block node] 

A <scope> activity must contain a <f low> or a <sequence> activity. A 
<scope> activity must contain placeholders for the input node 42 and the output node 44 in 
the block. 

An empty activity with the foUovdng pattern is a placeholdo* for the input node 

10 42: 

name = "Input." + [Name of Input node] 

An emply activity with the following pattern is a placeholder for the output node 

44: 

nfiune = "Output_" + [Name of Output node] 

13 These empty nodes are created in the structural text-based representation so that 

the representation can be equivalent in structure to the original grq>hical representation. Hie 
attribute containerAccessSeriailzabie has a de&ult value of no. Oth^ nodes inside a 
block are represented in the equivalent BPEL4WS representation as defined in this 
description of the preferred embodiment 

20 (6) Iterations : Iterations are represented by loop nodes in the graphical 

representations of the preferred embodiment A loop condition must be set on the node to 
determine under what condition this loop node should execute. If the loop condition evaluates 
to true, the loop node continues to execute any activities in its body. The loop body contains 
elements that run repeatedly as long as the condition is true. In the process tool, the loop body 

25 must contain both input and output nodes to represent the start and end of the flow in the loop 
node. 
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When an iteration is identified by the exporter, the pattern mapping corresponding 
to iterations is accessed to convert the iteration to a structural, text-based language 
representation. In the preferred embodiment, iterations are represented by <whiie> 
activities. A <whiie> activity has an attribute condition expressed in XPath, which 
5 determines when the <while> activity should execute. 

Figure 5a illustrates the contents of the body of a simple loop, as it would be 
displayed in the process tool. Figure 5b illustrates loop node 72 in a process, the loop having 
the loop body shown in figure 5a. 

An example of the conversion of a loop node such that shown in Figure 5b is 
10 shown the following BPLE4WS segment: 

<!— from BPEli4WS file — > 

<while conditions "get Input ( ) != null' names "Lo^"> 

<sequence> 

<einpty name= " Input_Input 1 " / > 
15 <empty naine="Output_Outputl" /> 

</sequeace> 

</Mila±le> 

The process shown in Figure Sb may be mapped to a structural text-based 
representation in accordance with the following segment: 

20 <!-- from BPEL4WS file — > 
<sequence> 

<receive container= " input " create Instances "yes" operation=*'RRROp" 
por tType= ■ ns2 : RRRPortType " / > 

<while condition* " getlnput ( ) J= null" naitie= " Loop " > 

25 <sequence> 

<ernpty name» •* lnput_Input 1 " / > 
<en^ty name= Output_Outputl " / > 
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</sequence> 
</while> 

<reply container^" output" operations "BtRROp" 
port1Vpe= "ns2 : RRRPortType " /> 

5 </sequence> 

The mapping involves converting the loop node to a <whiie> activity. All elements in the 
loop body are mapped to the appropriate activities according to the mappings of the preferred 
embodiment and nested widiin the <whiie> activity. Any activities nested within the 
<whiie> activities run repeatedly as long as the condition is true. To make both 
10 representations equivalent, two <einpty> activities are nested within the <while> activity to 
represent the mandatory input and output nodes in the loop body. 

A <whiie> activity represents a loop node such as the loop node 72 and has the 
following pattern: 

name = [Name of the loop node] 
15 condition = [boolean expression in Java] 

The <while> activity must contain a <f iow> or a <sequence> activity and 
placeholders for input node 62 and output node 64 in loop 60. For the while condition, 
boolean expressions must be placed in quotes. The BPEL4WS while condition represents the 
"if' condition in the loopCondition method for the loop 60. 

20 An empty activity with the following pattern is a placeholder for input node 62: 

name = "Input..'' + [Name of Input node] 

An empty activity with the following pattern is a placeholder for output node 64: 

name = "Outpi;t_" + [Name of Output node] 

These empty activities are created in the structural text-based representation so 
25 that the representation can be equivalent in structure to the original graphical representation. 



hi the preferred embodiment of the importer and exporter, the code must follow a 
certain format, illustrated below, for the exporter to extract the condition correctly. On 
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import* this format is generated and the BPEL4WS "while" condition is inserted into the "if 
statement- The code on import is also surrounded by a try/catch block to avoid any unhandled 
exceptions that might be thrown by the Java condition. For example: 

pfublic Boolean loopCondition_PlofwNode_2 ( ) | 
5 throws com.ibm.bpe.api.ProcessException { 

boolean result = true; 

// user code begin {Loop block Sxpression) 
try { 

if(getlnput() != null) 
10 result = true; 

else 

result = false; 

) 

catch (Exception e) {} 
15 // user code end 

return result; 

} 

(7) Receive Event (ability to wait for events to select a path of execution based on 
the event received): In the graph-based representations of the process tool diis feature is 
20 represented by a receive event node. Receive event nodes wait for an event and select a path 
of execution depending on the event received. Events are specified by one-way operations in 
the process tool, which are shown graphically as out terminals on the receive event node. An 
event occurs when die one-way operation that specifies the event is invoked 

When this feature is identified in a graphical representation, the exporter accesses 
25 the associated pattern mapping. In the preferred embodiment, the receive event node feature 
in the graphical representation is associated widi a pattern mapping to a BPEL4WS <pick> 
activity. 

A <pick> activity contains several <onMessage> structures. Each <onMes3age> 
defines an event diat the ^ick> activity accepts. It also specifies the path of execution if this 
30 event is received. All events defined in the receive event node are converted to <onHesBage> 
structures. These structures are then nested within the <pick> activity. Ail elements in the 
path of execution are converted according to the mappings described in this invention. The 
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resulting structure is nested within the corresponding <onMessage> structure to indicate the 
path to be executed when that event is received. 

Figure 6 illustrates a simple example process having a receive event node, as it 
may be displayed in a graphical representation. 

An example of how the pix)cess defined in the graphical representation of Figure 6 
may be mapped to a structural text-based representation is shown in accordance with the 
following example segment, based on the patt^ mapping: 

<l— from BPEL4WS file — > 
<flow> 

<links> 

<link names ■FlowConditionalControlConnection„l " /> 

<link naitie= " FlowConditionalControlConnection_2 " /> 
<link name="FlowConditionalControlConnection_3" /> 

</lixiks> 

<receive container^" input" create Instances "yes" operation=''YYYOp" 
portType= "ns2 ; YYYPortType " > 

<sour ce 1 inkName^ "Fl owCondi t ionalCont r olConnec t ioiu.1 " / > 

</rQceive> 

<pick createInstance="no'' name=''Pick"> 

<target linkName= "FlowConditionalControlCoimection^l " J> 

<onMessage container="eSEInputHsg" operations" EBSOp" 
port Types: "nsS : EEEPortType " > 

<invoke inputContainer=s''rRRInputMsg" names" A" operations "RRROp" 
outputContainer= " rRROutputMsg* portType= "ns5 : KRRPortType " > 

< source linkNaitte="FlowConditionaiControlCoiinection_2 " /> 

</invoke> 

</onMessage> 

<onMessage containers " dDDInputMsg " operat ion= " DDDOp " 
portTVPfi= "ns4 : DDDPortType " > 

<empty> 

<source lizi3cNanie= " FlowCondit ionalControlConnection_3 " /> 
</ empty > 
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</onMessage> 
< /pick> 

<invo]ce inputCoiitainer= " output " name= " Output_Output " 
operat ion= " CCCOneWayOp " portType= " ns 6 : CCCPor t Type • > 

5 <target linkName="FlowConditiorialControlConiiection__2"/> 

<target linkName^ "FlowConditionalControlCoimection_3 " /> 

</invoke> 

</flow> 

In Figure 6, the paths iadicated by control connections 84, 86 that connect to out tmninals 
ID 83, 85 on ieceiveeventnode82,iespectively, define the path of execution if the event 
represented by one of out terminals 83, 85 is received In the equivalent BPEL4WS 
representation, the <pick> activity corresponds to receive event node 82. The <onMessage> 
stnictuies correspond to out tenninals 83, 85 on recdve event node 82. The patfis indicated 
by the control connections 84, 86 from out terminals 83, 85 of receive event node 82 are 
15 captured in the corresponding <onMessage> structures. The operation and portType 
atuibutes of the <oiiMessage> structure define the event that receive event node 82 
responds. 

Out terminal 83 is connected to node A 88, which in turn is connected to output 
node 90. This is represented by the first <onHessage> structure, which has <invcke> activity 

20 Aembedded in it. Out terminal 85 is connected to output node 90 only. The second 

<oz]Message> Structure has an <empty> activity placeholder embedded to mark the source of 
the link to the output This link represents control connection 86 from out terminal 85 of 
receive event node pick 82 to output node 90. When creating receive event nodes in the 
process tool, variables for each tvGat must be set in order to export correctly because 

25 BPEL4WS requires <onMessage> to have a container defined. On export, the 

createinstance attribute is always set to no on the <piciO activity, as this does not start off 
the process. 

(8) Compensation : In the graphical representation described with reference to the 
preferred embodiment, compensation is achieved using service nodes. The compensation 
30 activity will run if the execution of the service node fails. 
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Whai the exporter detects a compensation activity, it accesses the appropriate 
pattern mapping. In the preferred embodiment, the pattern mapping includes a 
<coix^ensationHandler> structure. The activity nested within the <coxi^ensationHandler> 
structure will run to compensate an execution ftiluie. The exporter first creates a 
5 <compensatiocHandier> structure, then the compensation activity is mapped to the 
appropriate activity according to the nuq>pings described in this invention. The resulting 
activity is nested within the <campensationHar.dler> structure. For example, the 
compensation service defined for a service node is mapped to an <invoke> enclosed in a 
<con^ensationHandler> tag. 

iO In Figure 7, a compensation service is shown defined for node RRROp 102. 

An example of how a process such as that shown in Figure 7 is conv^ted by the 
exporter to a structural text-based representation is shown in the following BPEL4WS 
segment: 

<!-- from BPEI.4WS file — > 

15 <invoke inputContainer="rRRInputMsg" naiiLe=" RRROp" operation="RRRQp" 
outputContainer= " rRROutpucMsg " portType= " ns3 : RRRPortType " > 

<coinpensationHcUidler> 

<invoke inputContainer="rRRInputMsg" operations "EEEOp" 
portType= "1184 : EBEPortType " / > 

20 </GompensationHaiidler> 

</invoke> 

An <invo3ce> activity RRROp represents node RRROp 102. The <invoke> activity with the 
operation eeegp in the <conqpensationHandler> is the corresponding compensation defined. 
To confonn to the graphical representation, the inputcontainer for the compensation 
25 activity is always the input of the activity being compensated. 

(9) Correlation : Correlations are used in conjunction with input and receive event 
activities in a run-time system where multiple instances of the same process are running 
simultaneously. It is used to ensure that events received by the system are directed to the 
correct process instance. Correlations are set in methods associated with the input and receive 
CA9-2003-0070 - 27- 



CA 02443447 2003-09-30 



event nodes in the process. These methods specify the data to be used as the correlation ID. 
When the run-time system receives an event with a correlation ID set, the system will direct 
this event to the correct process instance with the same correlation ID. 

When a correlation in the graphical representation is identified, the exporter 
5 accesses the appropriate pattern mapping. In the preferred embodiment, a <correlation> 
element is included in for the pattern mapping. 

To use <correlation> in BPEL4WS» a correlation ID must be first defined in the 
BPEL4WS process. It is referenced by a <correlationSet> element A <correlation> 
structure is then created and nested within the <receive> activity, which corresponds to (he 
10 input node, and the <onMessage> structure of the <pick> activity, which corresponds to the 
receive event nodes in the graphical rq>resentation. Die <correiation> structure references 
the <correlatlonSet> element in order to specify which correlation ID is used. 

Figure 8 shows a graphical representation having input node 1 12 and receive 
event node 1 14. An example illustrating the conversion of the process shown in Figure 8 to a 
15 structural text-based representation is set out in the following segment: 

<l— from BPBL4WS file — > 

<correlationSets> 

<cor r e 1 at i onSe t name = " c or re lat i onlDSet ** 
properties="nsl : correlationID" /> 

20 </correlatlonSets> 

<sequence> 

<receive container=" input " cr€atelnstance=''yes" operatione'YYYQp" 
port'IVpe=''ns2 :YYYPortType"> 

<correlations> 

25 <correlation initiations "yes" pattern="in" 

sets^correlationlDSet" /> 

< /correlations> 



</receive> 
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<pick createInstance="no" name='' Event "> 

<onMessage containers " nessagel " operations « OneWayOpl " 
portTypea " ns3 : OneWayPpPT " > 

<correlations> 

5 <correlation initiation's "no" pattern="in'' 

set= " correlationlDSet ■ /> 

</correlations> 

<invoke inputContainer= "output" name=''Output_Outpuf 
operation= " ZZZOneWayOp" portT:ype= ''ns4 : ZZZPortType" /> 

10 </onMessage> 

</piclt> 

</seqaence> 

Referring to Figure 8, an assumption of the preferred embodiment is that if a correlation is 
defined for receive event node 1 14, a correlation is also defined for the process level input 

IS node 112 because it is assumed that the value of the correlation is initiated at die start of the 
process. Jf one or more getcorreiat ionid methods are provided by the user for input nodes 
or receive event nodes, a <correlation3et> named correlationXDSet is gena'ated in the 
BPEL4WS <proces6> and a bpws : property named correlationXD is generated in the 
definitions file, finplementations may have only one correlationset defined for each 

20 <process>. It refers to the prc^perty called correiationiD. The property is defined in the 
definitions file and is shown here: 

<]:^ws: property name = "correiationiD" type = "xsd: string" /> 

For an input node and out terminals of receive event nodes that have a 
getcorrelationxd method defined, a <correlation> Structure is defined for the 
25 <receive> activity and <onHessage> Structure. The <correXation> Structures refer to the 
same <correiationSet> named correlationlDSet. The <correiation> Structures are 
generated with the attribute pattern equal to in. The <correiation> for the <receive> 
activity has the attribute initiation equal to yes which initiates the value of the property 
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named correiationXD. The <correlation> for <onMes8age> Structures Set the attribute 

initiation equal tO no. 

In the preferred embodiment, the WSADBB code that defines the correlation for 
input nodes and receive event nodes follows the pattern below: 

5 correlationID = 

message . getPartName ( ) . getChildlNaiae ( ) . getChild2Naiae () — . 

The message in the above code is the input of the getcorrelatioziid method 
assodated widi the input nodes or the receive event nodes. The above code pattern will be 
translated to flie preferred embodiment of the structural text-based representation using a 

10 <bpws : proper tyAiias> element in the definition file to specify that the part or children of 
the part (if the part is a complex type) is used as the value for the correlation ID. Further, 
<bpws :propertyAlias> has an attribute called xnessageType. This is set to the type of the 
input parameter called message of the getcorrelat ionid method. In addition, 
<bpws : proper tyAlias> has an attribute called part and this is set to the PartName in the 

IS code. With respect to the above pattern, it is determined from the getPartNane ( ) portion. 
Finally, <bpws :propertyAiias> has an attribute called query whidi specifies where in the 
message to retrieve the value to be returned for the correlation ID. This is set to an XPath 
expression that looks like the following: 

qaery= " /PartNaine/ChildlNaine/Child2NaiRe/ ..." 

20 With reference to the above pattern, PartName is determined firom the 

getPartnaxae ( ) portion, childlNazne from the getChildlMame { } portion, child2Naxne from 
the getchild2Name ( ) portion and so on. 

For the method getCorrelationidyyyinpxitMsg, (he exporter retrieves the type 
of message to get the message type, and from getYyyinput ( ) , the exporter retrieves the part 
25 Since the part is not a complex type, the query is simply the Par tNaxne. If the part is a 
complex type, the query is built from the part and children of the part. 

An exanq>le, shown below, is the <propertyAl ias> built for the 
getCorrelationidMessagei method where the part is a complex type. On import, die 
message type, part and query string must refer to appropriate message and XSD types since 
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the <propertyAiias> wiD be imported in the same pattern for (he user code shown below, 
including a try/catch block to handle any exceptions that might be thrown. 

public static String getCorrelationldyyYMsg { 

com . yyy . w«i7jmsg . VYYXnputMsgMessage message) 
throws com.ibm.bpe.api.ProcessException { 
String correlationID = null; 

// user code begin {Correlation ID Expression} 
try { 

correlationID = message.getYYyinput ( ) ; 
} catch (Exception e) { 
} 

// user code end 
return correlationID; 

} 



<! — from BPEL4WS definitions file — > 

<bpws rpropertyAlias iuessageType= "ns2 : YYYInputMsg" part=" Yyy Input" 
proper tyName= "ns 3 : correlationID" ciuery= " /Yyy Input " /> 



piiblic static String get CorrelationldMessageK 
com. onewayop_;nsg.MessagelMessage message) 
throws com.ibm.bpe.api.ProcessException { 
String correlationID = null; 

// user code begin {Correlation ID S^qpression} 
try { 

correlationID = message getComplexO .getComplexNameO ; 
> catch (Exception e) { 
} 

// user code end 
return correlationID; 

} 



<• — from BPEL4WS definitions file — > 
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<bpws : property-Alias me s s ageType = "nsO .-Message 1 " part="Coir.plex*' 
propertyName=''ns3 rcorrelationlD^' ciuery=" /Complex/CornplGxName" /> 

flO) Variables : Variables are defined to store data used by other nodes in the 
process. Tn a graphical representation of a business process in the preferred embodinient, a 
variable type is defined by a Web Services Description Language (WSDL) niessage. 

When the exporter identifies a variable in the graphical representation, it accesses 
the corresponding pattern mapping. In the preferred embodiment, variables correspond to 
BPEL4WS <container> elements. The container type is defined by the same WSDL 
message as the variable. 

The following table represents a variable page in die process tool, which defines 
variables in the process: 



Name 


Message Type 


Description 


input 


TTTInputMsg 


User defined container 


output 


TTTOutputMsg 


User defined container 


aAAInputMsg 


AAAInputMsg 


User defined container 


rRRInputMsg 


RRRInputMsg 


User defined container 


rRROutputMsg 


RRROutputMsg 


User defined container 


tTTInputMsg 


TTTInputMsg 


User defined container 


tTTOutputMsg 


TTTOutputMsg 


User defined container 



The above variables in the process tool are mapped to the business process 
language as follows: 

<!— from BPEL4WS file — > 

<conta iner s> 

< container messageType 
<container messageType 
<container messageType 
<container messageType 
<container messageType 
<container messageType 
< container messageType 
<container messageType 

< / containers> 



= " ns2 : TTTInputMsg " name= " input " /> 
= " ns 2 : TTTOutputMsg " name= " output " / > 
= " ns3 : AAAInputMsg " name= " aAAInputMsg" /> 
= " ns 3 : AAAOutputMsg " name= " aAAOutputMsg » / > 
= " ns 4 : RRR I npu tMs g " name = " rRRInpu tMs g " / > 
= " ns 4 : RRROutputMsg " name= " rRROutputMsg " / > 
= "ns2 : TTTInputMsg" name= "tTTInputMsg" /> 
= " ns 2 : TTTOu tputMsg " name= " tTTOutputMsg " / > 
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fill Fault Handling : In the preferred embodiment, for a graphical representation 
of a business process, a service node, loop node or block node may throw an exception, 
represented by a fault terminal on the node. Each fault terminal represents a fault that could 
be thrown by the node. 

5 The fault terminals each have an associated connection element The path directed 

from a fault terminal defines how the process reacts if a fault is caught. An exception can be 
caught and thrown again. If the exception is thrown internally from a loop or a block body, 
then the parent element, i.e. the element whose body contains this loop or block node, should 
handle this exception. If the exception is thrown externally from the root process 
10 composition, then die process caller should handle the exception. In the preferred 
embodiment, handling of an exception is modelled using a fault node. 

When a fault situation is detected by the exporter, the corresponding pattern 
mapping is accessed. In the preferred embodiment, the mapping uses a <catch> structure to 
correspond to the fault terminal. A <catch> structure has an attribute f aultName. It defines 

15 the fault the <c:atch> structure should handle. All elements in the fault path are converted 
according to the mappings described in the invention. The resulting structure is nested within 
the <catch> structure. The container attribute of the <catch> structure represents the variable 
assigned to the fault terminal. Embedded in the <catch> are the activities that execute when 
the fault is caught. These represent the nodes that run following the control connections from 

20 a fault terminal of a node. 

Referring to Figure 9, servicenode A 194has fault terminal 195. An example 
illustrating the conversion of the process represented in Figure 9 to a structural text-based 
language is as follows: 

from EPEL4WS file — > 
25 <flow> 

<links> 

<link name="FlowConditionalControlConnection_l" f> 
<link name="FlowCcnditionalControlConnection_2 " /> 
<link narae= " FlowConditionalControlConnection_3 " /> 
30 <link namea " PlowCondi tionalControlConnec tion_4 " /> 

</links> 
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<receive containers " input " createlnstance= "yes " 
operations "TTTProcessOp " portType* "ns2 : TTTPortType " > 

<source linkName= *' FlowConditionalControlConnection^l " /> 

</receive> 

< invoke inputContainer= " vWInputMsg" name="A" operations "VWOp" 
outputContainer= • vWOutputMsg" portTypes^nsS : VWPortType" > 

< target linkNaine="FlowConditionalControlConnection_l"/> 
<source lin3cName="FlowConditionalControlConnection_2 "/> 

<catch £aultContainer=*'vWFaultMsg" £aultNaitte= "ns3 : wvFault "> 

<invoke inputContainer="rHRInputMsg" name="C" operation="RRROp" 
outputContainer= " rRROutputMsg" portType* "ns5 : RRRPortType ■ > 

<source linkName= "FlcwConditionalControlConnection_3 " / > 

</invoke> 

</catch> 

</ invoke> 

< invoke inputContainer="aAAInputMsg'' name="B" operation="AAAOp" 
outputContainer-"aAAOutpiitMsg" portType="ns4 : AAAPortType"> 

<soixrce linkNaiiie= "FlowConca.itionalControlConnection_4 " /> 
<target linkNaine= ■FlowConditionalControlConnection_2 " /> 

</'invoke> 

<reply containers " output " operations " TTTProcessOp " 
portType= "ns2 : TTTPortType " > 

<target linkName=" FlowConditionalControlConnectionJ " /> 
< target linkName= " FlowConditionalControlConnection_4 " / > 

</reply> 

</flow> 

The attribute suppress JoinFai lure must be set equal to yes in the <process> 
dement in which this code example is nested. The <receive> activity, the <invoke> activity 
A, and the <invoke> activity B represent input node 192 to node A 194 to node B 198, The 
<invoke> activity A has a <catch> stmcture specifying the fault name and container. The 
<catch> structure contains the <invoke> activity C representing control connection 196 
from fault terminal 195 on node A 1 94 to node C 200. 

When a fault is caught for node A 1 94, node C 200 v^ill run followed by output 

node 202. Node B 198 will not run. In the example provided above, if a fault is caught for the 

<invoke> activity A, activity A is halted as a result of the fault which then results in all 
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outgoing links being set to negative. Consequently, the join condition at activity B is 
evaluated to false since it is the target of the link source oource 

1 inkName = " F 1 owC ondi t i ona IC on t r o 1 

Connection_2"/>, and this activity is skipped. The inline fault handler mapping for 
5 <invoke> is the only mapping supported by the tool of the preferred embodiment. 

When a fault may be thown more than once, it is mapped to different activities 
depending on whether the exporter determines that the exception is thrown internally or 
externally. If the fault is thrown internally, i.e. the fault node is in the loop or block body, this 
fault node will be represented by a <throw> activity in the preferred embodiment If the fault 
10 is thrown externally, i.e. the fault node is in the root process composition, if the process is 
synchronous, this fault node will be modelled as a <repiy> activity in the preferred 
embodiment. If the process is asynchronous, this fault node will be modelled as an <invoke> 
activity instead. 

When the fault is thrown internally in a block or a loop body, in the prefi^red 
15 embodiment, the exporter applies a mapping in which a <throw> activity is used to represent 
the fault node. A <f aultHandlers> clement is put inside the <scope> activity of the block. 
For each fault terminal, there is a <catch> structure inside the <£auXtHandlers> element. 
The <catch> structure shows the fault path from the fault terminal. The f aultName attribute 
of the <catch> element is set to the qualified message tjpe of the fault being caught. 

20 An example illustrating the use of a <throw> activity in the preferred embodiment 

is as follows: 

<I— from BPEL4WS file --> 
<containers> 

<container messageType^-nsl :RRRInput" naities'RRRContainer" /> 
25 </ container s> 

<throw fa\iltContainer="RRRContainer" faultName="nsl:RRR Input" 
nam€= InnerFaul t " / > 
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Figures 10 and 1 1 provide an illustration of a fault thrown in a block. Figure 10 
shows the body of a block with a fault node 212. Figure 1 1 shows a block node 222 with a 
fault terminal 223, the body of the block being that shown in Figure 10. 

An example illustrating a conversion of the graphical representalion of the process 
shown in Figure 1 1 is as follows: 

<!-- from BPEL4WS file --> 
<f lcw> 

<links> 

<link name=''FlowConditionalCcntrolConnection_l'' /> 
<link names " FlowConclitionalControlCoimection_2 " /> 
<link name="FlowConditionalControlCoimectioiu3" /> 

</liiiks> 

< receive containers" input " create Ins tance= "yes " 
operation="TTTProcessOp'* portl^e="ns2 :TTTPortType"> 

<source linlcName="FlowConditionControlConnection_l " / > 

< / receive> 

< scope containerAccessSerializable="no" name=''Block"> 

<faultHandlers> 

<catch f aul tName= " ns3 : QQQPaultMsg " > 

<invoke inputContainer="rRRInpTjtMsg" name="RRRCp" 
operation= " RRROp " outputContainer= " rRROutputMsg" 
portType= "ns4 : RRRPor tType" > 

<source 

lin3cNaTOe= " FlowCondi tionalControlConnec tion^3 • /> 
</invoke> 
</catch> 
< / f aul t Handler s> 
<seguence> 

<target linkNaine="FlowConditionalControlConnection_l " /> 
<source linkName=''FlowConditionalControlConnection_2"/> 
<empty name= " Input^Input " / > 

<invoke inputContainer=''qQQInputMsg" naBae="QQQOp'' 
operat ion= " QQQOp " outputContainer = " qQQOutputMsg " 
portType= "ns3 : QQQPor tType " > 
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<catch f aultContainer = " qQQFaul tMsg " 
f aul tUarne « " ns 3 : qqqPaul t " > 

< throw £aultCoxitainer= " fault " 

f aultKame= " ns3 : QQQFaul tMsg " name= " Fault " /> 

</catch> 

</invoke> 

<ei(©ty name= " Output_Output " /> 
</sequence> 
</scope> 

< reply container^" output" operation="TTTProcessOp" 
po r tType= " ns2 : TTTPor tType " > 

<target linkNaine= '*FlowConditionalControlConnection_2 " / > 
<target 1 inkNaitie= " FlowConditionalControlConnec t ion_3 " / > 

</reply> 

</f low> 

The example above shows a <scope> within a <f iow> activity. Out terminal 228 
of service node RRROp 227 is connected to output node 230. The <reply> activity 
representing output node 230 is placed outside a <se<iuence> containing the activity 
represented by block node 222. The link named FiowConditionalControlCoiinection_2 
from the primary activity of the <scope> element to the <reply> element represents control 
connection 225. For control connection 226 from the fault terminal 223 of the block node 
222 to service node 227, the activity representing service node 227 would be placed in the 
<catch> structure. The <invoke> activity QQQOp, shown in the <scope>, has a <catch> 
structure. Inside this <catch> is the <throw> activity that represents fault node 212 shown in 
the block body. 

Figures 12 and 13 provide an illustration of a fault thrown in a loop. Figure 12 
shows the body of a loop with a fault node 242. Figure 13 shows a loop node 252 with a fault 
terminal 253, the body of the loop being that shown in Figure 12. 

An example illustrating a conversion of the graphical representation of the process 
shown in Figure 13 is as follows: 

<•-- from BPEL4WS file — > 
<flow> 
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<links> 

<link ziame="FlowConditionalControlConnection„l" /> 
<lin]c name=*FlowConditionalControlConnection_2 "/> 
<link name= " FlowCondi tionaxControlConnection_3 " /> 

</Xinks> 

<receive container=" input" createlnstance="yes" 
operations " TTTProcessOp " portType= "ns2 : TTTPortType " > 

< source linkNames^FlowConditionalControlConnection^l" /> 

</receive> 

<scope containerAccessSerializcd3le= -no " > 
< f aultHandler s> 

<catch f aultNaiae= "ns3 2 QQQFaultMsg" > 
<ei^pty> 

<source 

linkNaine= "FlowConditionalControlConnection_3 " /> 
</ernpty> 
</catch> 
< / f aul tHandl er s> 

<while condition="getlnput () -getTttlnputO .lengthO 1= 0" 
names " Loop " > 

<target linkNames "FlowConditionalControlCozmec tion^l " /> 
< source 

1 inkNames " FlowConditionalControlConnection_2 '* /> 
<3equence> 

<enispty name= " lnput_lnput " / > 

< invoke inputContainer="qQQInputMsg'' naine="QQQOp" 
opera t ion= " QQQOp " outputContainer= • qQQOutputMsg " 
portType= " ns3 : QQQPortType " > 

<catch faultContainers^qOOFaultMsg" 
£aul tName= " ns 3 : qqgPau 1 1 " > 

<throw faultContainer= "fault" 

f aul tName= "nsS ; QQQFaultMsg" name= "Fault " /> 

</catch> 

</invoke> 

<einpty naine= " Output_Output " / > 
</sequence> 
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</while> 
</scope> 

<reply containers "output" operations "TTTProcessOp" 
por tType= ''ns2 : TTTPortType " > 

5 <target linkName=''PlowConditionalControlConnection^2 " /> 

<target linkName="FlowConditionalControlConnectioi^_3 " /> 

</reply> 

</flow> 

The above exanople shows a <scope> with a <whiie> activity named Loop. Fault temiiiial 
10 253 of loop node 252 goes to output node 257, In this particular example, a <reply> 
activity representing output node 257 is placed outside the outer <scope>. A link, named 
PlowConditionalControlConnection_2, fiom the <while> tO the <reply> represents 
control connection 255 from out terminal 254 of loop node 252 to output node 257. For 
control connection 256 from fault terminal 253 of loop node 252 to ou^ut node 257, an 
15 <empty> activity with no name is used as placeholder in the <catch> structure. A placeholder 
is used when the activity it represents cannot be placed within the <catch> structure. 

The <invoke> activity QQQOp, shown in the <whiie>, has a <catch> structure. Inside this 
<catch> is the <throw> activity that represents fault node 242 shown in loop body 240. 

(12^ Transition Conditions : In the graphical representation of the preferred 
20 embodiment, a transition condition determines whether the process modelled in the graph will 
take a path as specified by the defined transition. The pattern mapping for this feature is to 
translate the condition to an attribute in the <source> element of a <link> element 
representing the transition in the strucmral text-based representation. The 
trans itioncondit ion attribute of the <source> element is used to specify the condition on 
25 a control connection (in the preferred embodiment, a boolean expression in Java). The default 
condition is true for both BPEL4WS and the graphical representation. 

In the preferred embodiment, the name of each <link> element corresponds to the 
control connection name in the process tool unless it has a condition of otherwise. A 
condition of otherwise means that if all other connections with the same source node fail 
30 (meaning their condition evaluates to false), the control connection that has an otherwise 
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condition set evaluates to true. If the condition on the control connection is otherwise, the 
<xizik> name has the following naming convention: 

name = [Connection Name] + "^otherwise* 

If the condition on the control connection is otherwise, the 
transitioncondition for the <source> is the NOT of the conditions of all the oth^ control 
connections OR'ed together (i.e. control connections with the same source), ff there is a 
transition condition present, other links are used to maintain proper semantics. For the 
transition condition, boolean expressions are placed in quotes and the BPEL4WS transition 
condition represents the ''if condition in the condition metiiod of the control connection if 
the condition is set to Java in the process tool. When the code follows a certain format, 
illustrated below, the exporter may extract the condition correctly. On import, this format is 
generated and the BPEL4WS transition condition is inserted into the statement The code 
on import is also surrounded by a try/catdi block to avoid any unhandled exceptions that 
mig^t be thrown by the Java condition. 

public boolean controlCondition_FlowNode2_out_FlouNode6_in() 
throws com.ihm.bpe.api.ProcessException { 
boolean result = true; 

// user code begin {Condition Expression} 
try { 

if (getlnput 0 .getTttlnputO .length 0 != 0) 
result = true; 

else 

result = false; 
} catch (Exception e) { 
} 

// user code end 
return result; 

} 

Figure 14 illustrates a business process containing multiple links with conditions 
set on them, as it would be displayed in by the graphical representation of the preferred 
embodiment An example illustrating a mapping to a structural text-based representation 
according to the preferred embodiment is as follows: 



CA9-2003-0070 



-40- 



CA 02443447 2003-09-30 



<!-- from BPEL4WS file — > 
<flow> 

<links> 

<link na2ne="PlowConditionalCoiitrolConnection_l'' /> 

<link name= " FlowConditionalControlCoiinection_2 " /> 

<link name= " PlowConditionalControlCoimec tion__3_otherwise • /> 

<link name=*'PlowConditioiialControlConnection_4 " / > 

<link name= " FlowConditi onalCor.tr olConnectioiL-5 " /> 

<link naiae= " FlowCondi t ionalControlCoimect ion_6 " /> 

<link name= "PlowCcnditionalControlConnection_7 " /> 

</links> 

<receive container='' input" createlnstance=''yes " 
operations " TTTProcessOp " por tType= " ns2 : TTTPor tType " > 

<source linkName^'TlowConditionalControlConnection^l" /> 

</receiv€> 

<invoke ii3putContainer="aAAInputMsg" name="A" operations "AAAQp" 
outputContainer= ■ eAAOutputMag " por tType= "ns3 ; AAAPortlVpe " > 

<target linkNaaies^FlowConditionalControlConnection^l" /> 

<source lin3dNaine="FlowConditionalControlConnection_2 " 

trans i t ionCondi t ion= " get Input < ) . getTt t Ii^ut { ) . length ( ) ! « o " / > 

<source linkNaine= "FlowConditionalControlConnection^S^otherwise" 

transitionCondition^" ! (false | | 

get Input ( ) . getTtt Input ( ) . length {) ! = 0 > " /> 

<source linkName= ••FlowConditionalControlConnection^4 " 

transitionCondition= " false " /> 

</invoke> 

< invoke iiiputContainer="rRRInputMsg" names" B" operations "RRROp" 
outputContainers " rRROutputMsg " portType= ■ ns4 : RRRPortType " > 

<source linkNane= "FlowConditionalControlConnection^S " / > 

<target 

linkName= "FlowConditionalControlConnect ion_3„otherwise " /> 
</invoke> 

<enipty name="En]pty_En^ty"> 

<source linkName= "PlowConditionalControlCoimectio]n_6 " 
treuisitionConditions " false" /> 

< target linkName= ''FlowConditionalControlConnection_4 " /> 
</enapty> 

<invoke inputContainera " tTTInputMsg " name="C" operations "TTTQp" 
outputContainer= " tTTOutputMsg " por tType= " ns2 : TTTPor tType " > 
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<source linkName»''FlowConclitionalControlConnection_7" /> 
<target lin)cNaine» "FlowConditionalControlConnect ion_2 " /> 
<target linkName="FlovX;onditionalControlConnection_6" /> 

</invoke> 

5 

<reply container=' output" operat ion= " TTTProcessQp " 

portType= "ns2 : TTTPortType " > 

< target linkName= "PlowConditionalControlConnection_5 " /> 
<target linl^aine= " PlowCondi tionalControlConnec t ion_7 " /> 

10 </reply> 

</f low> 

Referring to Figure 14, the link representing control connection 264 has its 
transition condition set equal to otherwise; the link representing control connection 266 has 
its transition condition set equal to getinput < ) .getTttinput ( ) . length i = o; the link 
15 representing control connection 268 has its transition condition set equal to false; and the 
link representing control connection 270 has its transition condition set equal to false. 

When control connections with conditions originate from a fault terminal or a 
terminal on a receive event node, an <empty> activity is created inside the appropriate 
<catch> or <onMessage> element to hold the <source> element for the link. In the preferred 
20 embodiment, the BPEL4WS specification indicates that <source> elements cannot be placed 
directly inside <catch> elements and they cannot be placed in the parent <invoke> activity, 
as the correct path/terminal corresponding to the <invoke> element is associated with the 
link. 

Figure 15 illustrates the situation described above with a <catch> element 
25 involved. An example illustrating the ms^ping of the business process described in the 
graphical representation of Figure IS is as follows: 

<!— from BPEL4WS file — > 
<f low> 

<links> 

30 <link name="FlowConditionalControlConnection„l'*/> 

<link naine="FlowConditionalControlConnection_2 "/> 
<link r.aine="PlowConditionalControlConnection_3_otherwsie" /> 
<link naine="FlowConditionalControlConnection_4 V> 
< 1 ink name = " Fl owCondi t i ona ICon t r o 1 Connec t i on_5 " / > 
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<link names " FlowConditionalControlCormection_6 " /> 
<link naineo"FlowConditionalControlCoimectio3x.7" /> 

</links> 

<receive container^ " input " cr8atelnstance="yes" 
operations " TTTProces sQp " portType= "ns2 : TTTPortType " > 

<aource linMame- " FlowConditionalControlCozmection_l " / > 

</receive> 

<invoke inputContainer= "bBBInputMsg" name="BBBOp'' operations "BBBOp" 
outputContainer= "bBBOutputMsg " portType= "ns3 : BBBPortType " > 

<target lin]«Name=*FlowConditionalControlConnection_l'' /> 

<source linkName="FlowConditionalControlConnection„6''/> 

<catch f aultContainer= "bBBFaultMsg" f aultName="ns3 :bbbFault"> 

<f low> 

<enipty> 

< source linkNcuae= " FlowConditionalControlConnec tion_2 " 
transit ionCondition=" get Input ( ) .getTtt Input ( ) . length ( ) &gt ; 
0V> 

<so\irce 

1 inkNaiae= "FlowConditionalControlConnection^3_otherwise " 
transitionCondition= " 1 (getlnput ( > .getTttlnput ( ) . length ( ) > 
0) V> 

</ empty > 

< invoke inputContainer= " tTTInputMsg ■ name= " TTTOp ■ 
operations " TTTOp ■ ou tputContainer = ■ tTTOutputMsg ■ 
portiypess " ns2 : TTTPortType ■ > 

<source linkNaiQes"FlowConditionalControlConnection_.4'' / 

<target linkName- " PlowCondit ionalControlConnect ion_2 " / 

</invoke> 

< invoke inputContainer="rRRlnputMsg" naine=''RRROp" 
operat ion= " RRRQp " ou tputContaine r = " rRROutputMsg " 
port Type=s " ns 5 : RRRPor tType ' > 

<source linJtName* " FlowConditionalControlConnection_5 " / 

< target 

linkName= " FlowCondi tionalControlConnec tion^3_otherwise ■ /> 

</invoke> 
</f low> 
</catch> 
</invoke> 
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<invoke inputContainer«"aAAInputMsg" names "AAAOp" operations "AAAOp" 
outputContainer= " aAAOutputMsg " portType= "ns4 ; AAAPortType " > 

<source linkNaine= "FlowConditionalControlConnection.? " /> 
<target 1 inkNaine= " PlowCondit ionalControlConnec t ion_6 " / > 

5 </invo]ce> 

<reply container='' output" operations "TTTProcessQp" 
por tType= " ns2 : TTTPor tType •* > 

<target lin3cNaine="FlowConditionalControlConnection_4 " /> 
<target linkName= "FlowConditionalControlConnection^S " /> 
10 <target liiikName="FlowConditionalControlConnection_7 " /> 

</reply> 

</f low> 

Referring to Figure 15, an <eit^ty> element is generated in the <catch> elemrat to hold the 
two <3ource> elements required to describe two control connections 283, 284 (link names 

15 FlowConditionalControlCoimection_2 and FlowCoiiditionalControlCozinectioEL.39 
respectively) with transition conditions coming from the fault terminal 282. The link 
lepiesenting control connection 283 has its transition condition equal to 
getinpub ( ) . getTttinput ( ) . length > 0 and the link representing control connection 284 
has its transition condition equal to otherwise. If no fault is thrown in the above example, 

20 then the process will flow through the link FlowConditionaXControlconnection^e . As 
discussed above, the attribute suppress joinFaiiure is set equal to yes in the <process> 
element in which this code example is nested. 

To sunmiarize, the following table sets out features and their associated pattern 
mappings. As described above, when converting from graphical to structural text-based 
25 representations, features as set out in the table are identified in the graphical representations 
and the associated pattern miappings are used to define equivalent code in a structural text- 
based language: 



Feature 


Pattern Mapping 


synchronous/asyndironous 
processes 


a synchronous process is r^resented as having a 
<receive> activity as its input interface, and a 
<reply> activity as its output interface 



'(• 
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an asynchronous process is represented as having a 
<receive> activity as its input interface, and an 
<invoke> activity as its output interface 


request/response activity 


an <invoke> activity with attributes inputContainer 
and outputCcntainer to specify input and output 
containers assigned to the activity 


one-way activity 


an <invoke> activity, with attribute inputContainer 
(no outputContainer) 


empty node 


an <empty> activity (naming convention to include 
node name) 


block 


a <scope> activity (two <empty> activities nested 
within the <scope> to represent Ae input and output 
nodes in the block body) 


iteration 


a <while> activity (attribute condition equivalent to 
loop condition in loop node; two <empty> activities 
nested within the <while> activity to represent input 
and ou^ut nodes in the loop body). 


receive event 


a <pick> activity (contains <onMessage> structures 
to define events accepted by <pick> activity - 
corresponding to events defined in the receive event 
node) 


compensation 


a <compensationHandler> structure (acti\nity within 
the structure will run to compensate an execution 
failure) 


correlation 


a <coiielation> element (a correlation ID is defined 
and referenced by a <cornelationSet> elem»t>; the 
<correIation> element is nested within a <receivc> 
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activity representing the input node, and within all 
<pick> activities corresponding to the receive event 
nodes; <coireIation> structure references 
<correlationSet> element to specify the coxrelation 
ID used) 


variables 


containers 


fault handling 


a <catch> snructure (containing elements in the fault 
path) if the fault is only thrown once 

if the fault can be caught and thrown again (hen 

(a) if thrown internally: a <throw> activity; or 

(b) if thrown externally: a <reply> activity 


transition condition 


an attribute in the <source> element of a <link> 
element representing die transition 



In addition, as those skilled in the art will appreciate, a structural text-based 
representation of a business process which is coded so as to conform with the above pattern 
mapping definitions may be imported to produce a graphical representation of the business 
5 process. For such a structural text-based representation to be conecdy converted, the 

representation should be written with reference to the pattern mappings described above. To 
ensure correct conversion, the text-based representation employs naming conventions such as 
those set out in the above detailed description to avoid ambiguity or error in the conversion to 
a graphical representation. 

10 For example, in an asynchronous process, service nodes, output nodes and fault 

nodes may all be represented by <invoke> activities in BPEL4WS. The importer must 
therefore evaluate the activity in order to determine the appropriate corresponding feature. If 
the importer does not determine that the <invoke> activity is an output or a fault node under 
the naming convention, then the activity is imported as a sa^^ice node. Sinularly, only 
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<eit^ty> activities in the structural text-based representation of the preferred embodiment tiiat 
follow the naming convention set out above will be imported as empty nodes. Other <empty> 
activities that do not follow this convention may be present in the text-based representation 
only as a placeholder. In the preferred embodiment, the exporter will ^ply these naming 
5 conventions when a graphical representation of a business process is converted to a structural, 
text-based representation, so that a reverse conversion process aiay be ^plied when the text- 
based representation is imported to a graphical process tool. 

In the preferred embodiment, the graphical representation supports the use of Java 
code in several contexts. The structured text-based language referred to in the description of 

10 the preferred embodiment supports XPath code. Both Java and XPath code are commonly 
used and the conversion from graphical to structured text-based representations will also 
include a corresponding conversion from Java to XPath. For this reason, the preferred 
embodiment handles the case where the gr^hical representation references Java code and/or 
the structural text based representation references XPath code. A description of how certain 

15 conversion steps are carried out is set out below: 

Java Snippet Nodes: Java snippet nodes are supported in the graphical 
representations of the preferred embodiment and allow for execution of a piece of Java code 
written by the users by referencing the code in a Java Snippet Node in the graphical 
representation. 

20 When the exporter of the preferred embodiment identifies a Java snippet node, it 

access a corresponding pattern mapping. In the prefened embodiment, the equivalent 
BPEL4WS representation applied using the pattern mapping includes the BPEL+ language 
extension such that a <wswf : script> activity represents a Java snippy node. 

Hius, the process shown in Figure 3 may be mapped to a structural text-based 
25 representation in accordance widi the following segment: 

<!— from BPE1.4WS file — > 
<sequence> 

<receive container= "input" createlnst€uice=:**yes" operation=''RRRO!P" 
portType= "1182 :RRRPortType" /> 
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<eitipty names " Empty_NodeA " / > 

<wswf : script name= " JavaSn ippet " wswf : language= " Java " > 

getOutput ( ) . setRrrOutput {get Input ( ) , getRrrli^t ( ) ) ; </wswf : script> 

<reply container^" output" operation»"RRROp" 
5 portType="ns2:RRRPortType*'/> 

</sequence> 

A <wswf : 6cript> activity corrcsponding to a Java snippet node such as the Java 
snippet node 34 has the follo^\'ing pattern: 

name = [Name of Java Snippet node] 
10 wswf : language = " Java " 

The Java content between the user code begin and end strings from the method 
body of tfie Java snippet node is placed in between the <wsvf : scr ipt> start and end tags. In 
this manner, the Java code in a Java Snippet Node in the graphical representation may be 
represented in die structural text-based representation. 

15 Assignment and Condition Expressions : Java expressions used for assignments 

and condition evaluations are translated to corresponding XPath expressions, and they are set 
on the corresponding elements in the business process language. 

A pattern conversion from a Java snippet node to a <wswf : script> activity is 
described as an extension to the BFEL4WS standard. In some cases, if the piece of Java code 
20 performs an assignment operation, the Java snippet node can be represented as an <assi9n> 
acdvi^ in the equivalent 6PEL4WS representation. The conversion using an <assign> 
activity is useful if the resulting BPEL4WS documents are used in situations where BPEL 
Extensions elements are not supported. 

Additionally, when convming from a business process language representation to 
25 a process graph-based representation, XPath expressions are translated to Java codes and 
assigned to the corresponding elements in the process graph-based representation. 
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Assignments : An assignment is specified in a language such as Java. In the 
graphical repiesentation of the preferred embodiment, an assignment is specified in Java and 
enclosed in a Java snippet node. 

Assignment code in a Java snippet node, corresponding to a variable assignment, 
5 is mapped to an <ass ign> activity in BPEL4WS, The Java code is mapped to XPath as 
specified in BPEL4WS. Several, but not all, assignment code patterns are siq)ported in this 
mapping. 

Figure 16 illustrates a simple process, containing muldple Java snippet nodes with 
assignment code set on them. There are two variables, ixiputMsg and OutputHsg, defined in 
10 this process. They both contain two part elements, stringPaxt and intPart. Node A 322 
has assignment code getoutMsg ( ) . setstringPart ( "string" ) ; node B 324 has 
assignment code getOutMsg ( ) . setxntPart (looo) ; node C 326 has assignment code 

getOutputMsg ( ) . getStringPart ( getlnputMsg ( ) . getStringPart ( ) ) . 

An example of the mapping of the process shown in Figure 16 to a text-based 
15 structural representation in accordance with the preferred embodiment is as follows: 

<!— from BPEL4WS file --> 
<sequence> 

<rec€ive container=''InputMsg" create Instances' "yes" 
operation-- " ZZZProcesspp " portTyp€= "nsS : ZZZPortType " /> 

20 <assign naine="A''> 

<copy> 

<frGm e3<pression= " 'string' 'V> 
<to containers "OutputMsg* part=''StringPart''/> 
</copy> 
25 </assign> 

<assign name="B"> 
<copy> 
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<£rom e3Q>ression= "number (1000) "/> 
<to containers "OutputMsg" par t=»Int Part "/> 

</copy> 
</assisrn> 
<as6ign naine=''C''> 
<copy> 

<froia container- "inputMsg" part=''StringPart" /> 
<to container="OutputMsg" part="StringPart" /> 

</copy> 

10 </assign> 

<r€ply container = " OutputMsg " operat ion= " ZZZProcessOp " 
p»or tType*= "ns3 : ZZZPortType " / > 

For Java snippet nodes, an <assign> activity assigns data to and from a variable. 
In this case, an <assign> activity is generated for Java snippet nodes. It has the following 
15 pattern: 

name = (Name of the Java snippet node] 

Each Java snippet node must contain exactly one line of code that follows a 
certain format in order for the exporter to extract and convert it correctly. In the preferred 
embodiment there are three formats supported by the exporter, which are described below. 
20 Each variable defined in the process is generated to a Java backing class. This class contains 
the getter and setter methods to allow users to manipulate the data of that variable. 

Code pattern 1 has the following format; 

getVariableName ( ) . setPartMame ( " literal string" ) ; 

The code assigns a literal string to a part of a variable. variableName is the name 
25 of the variable involved in the assignment Note that this variable is defined in the process. 
PartName is the name of the part defined in the specified variable. It is of string type. Note 



5 
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that this part exists in the message type defined for the variable. The literal string is 
surrounded by quotations. 

In the preferred embodinient, an example of the translation of Java snippet nodes 
with code written in the above format is the following: 

5 <assign><copy> 

<from eacpressions" ' literal string '"/> 

<to container="VariableName'' part=''PartNajtte"/> 

< / c opy>< / ass i gn> 

The <f ram> construct defines the source of the assignment In this case» it is a 
10 literal string. The <to> construct defines the target of the assignment It has attributes 
container and part to specify where the data should be assigned. 

Code pattern 2 has the following format: 
getVariableName ( ) . setPartNaiae ( integer ) ; 

The code assigns an inte^r value to a part of a variable. variableName is the 
1 5 name of the variable involved in the assignment Note that this variable is defined in the 
process. PartName is the name of the part defined in the specified variable. It is of integer 
type. Note that this part exists in the message type defined for the variable. 

In the preferred embodiment, an example of the translation of Java snippet nodes 
with code written in the second format is the following: 

20 <assign><copy> 

<f rom express ion= "n\jmber ( integer ) " / > 

<to containers "VariableName" parts " PartName " /> 

< / copy>< / as sign> 

The <£roin> construct defines the source of the assignment In this case, it is an 
25 integer. It uses a built-in function niimber () for the conversion, since every attribute is 
interpreted as a string in BPEL4WS document The <to> construct defines the target of the 
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assignment It has attributes container and part to specify where the data should be 
assigned. 

Code pattern 3 has the following format: 

getVariablelName ( ) . set PartlNaioe <getVariable2Name { ) . getPart2Naxne { ) ) 

5 ; 

The code assigns the value of a variable part to anothar variable part. The variable 
parts is of type integer or string. The souixe and target variable part are of the same type. 
varieODieiName is the name of the target variable involved in the assignment Note that this 
variable is defined in die process. Variable2Name is the name of the source variable involved 
10 in the assignment Note that this variable is defined in the process. PartlName is the name of 
the target part whose value is being updated by the assignment Note that this part exists in 
the message type defined for the variable. Par t2Name is the name of the source part ixoin 
which the assignment obtains the value. Note that this part exists in the message type defined 
for the variable. 

15 In the preferred embodiment, an example of the translation of Java snippet nodes 

with code written in the third fonnat is the following: 

<as s ign><copy> 

<from container="Variable2Name'' part="Part2Name" /> 
<to containers " Variable INaiae " part= " Part INcune " / > 
20 </copy></assign> 

The <f rom> construct defines the source of the assignment In this case, it has 
attributes container and part to specify where the data is located. The <to> construct 
defines the target of the assignment It has attributes container and part to specify where 
the data should be assigned. 

25 Conditions : G>nditioDS include both loop conditions and transition conditions. A 

loop condition determines whether a loop node should execute, whereas a transition condition 
detennines whether the process should take the path directed by that transition. In the 
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graphical representation of the preferred embodiment, conditions are pmfeiably expressed in 
Java. In the preferred embodiment in BPEL4WS, conditions are expressed in XPath. 

Figure 17 illustrates a simple process, containing multiple links with conditions 
set on them, as it would be displayed in the process tool. There are two variables, inputMsg 

5 and outputMsg, defined in diis process. They both contain two part elements, stringPart 
and intPart. The link A to B for control connection 332 has Java condition 
getinputMsg ( ) . getstr ingPart ( ) == " string " ; the link B to C for control connection 
334 has Java condition getinputMsg { ) . getintPart { ) ! = 1000; and the link C to Output 
for control connection 336 has Java condition getOutputMsg ( ) . getstringPart () J = 

10 getinputMsg ( ) . getstringPart ( ) . In the following BPEL4WS example, more <link:> 
elements are created than listed above, <link> elements are also created for process 
execution control reasons other than to describe connection conditions. 



structural text-based language by the exporter in accordance witih the preferred embodiment is 



An example illustrating the mapping of the process shown in Figure 17 to a 



15 



as follows: 



from BPEL4WS file — > 



<f low> 



<links> 



20 



<link names "FloXfjConditionalControlConnection_3 » /> 
<link name=*FlowConditionalControlCozuiection_4" /> 
<link name* " PlowCondit ionalControlConnect ion_5 " / > 



</linlcs> 



<seguence> 



25 



<receive container=" InputMsg" createlnstance=:"yes" 
operation= " ZZZProcessOp" portType= "ns^ : ZZZPortType " > 



<source 1 inkName= " DPELink^eceiveToA" /> 



</receive> 
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< invoke inputCon ta iner = " ■ naine= " A " operat ions= " AAAQp " 
portType= ■ns2 ; AAAPortType " > 

<source linlcNaine= "PlowConditionalControlConnection^3 • 
trans it ionCondi tion= "bpws : getContainerData { ' InputMsg ' , 
' Str ingPart ' ) = ' string " / > 

</ invoke > 

< invoke inputContainer= " " naxne=''B'' operat ion* "RRRQp" 
portType= "ns2 : RRRPortType " > 

<source 1 inkName= ■FlowConditionalControlConnection_4 " 
trans itionCondit ion* "bpws : getContainerData ( • InputMsg ' , ' IntPart ' ) ! =1000 " /> 

< target linkName^ "?lowConditionalControlConaection^3 " / > 

</invoke> 

<invoke inputContainer=s" " name=''C" operations "TTTQp" 
portType= "ns2 : TTTPortType " > 

<source linkNaine= "FlowConditionalControlConnection^S " 
transi tionCondition= "bpws : getContainerData ( ' OutputKsg • , 
' StringPart ' ) I =hpws : getContainerData ( • InputMsg * , • StringPart • ) " /> 

<t£u:get lixUcName- "FXowConditionalControlConnection_4 " / > 

</ invoke > 

<reply container^ " Ou tputMsg * operat ion= " ZZZProcessOp " 
portType= " ns3 : ZZZPor tType ■ > 

<target linkNaine="FlowConditionalControlConnection^5''/> 

</reply> 

</sequence> 

</flow> 

The mapping involves translating the condition expressed in Java to that expressed 

in XPath, and assigning the resulting expression to the corresponding element A transition 

condition is saved as an attribute in the <source> element of the <link> element that 

represents the transition. A loop condition is saved as an attribute of a <while> activity as 

detailed under "Iterations." 
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For a transidon condition, the required elements are generated as desoibed. For a 
loop condition, a <whiXe> corresponding to a loop node must be generated. The code must 
follow certain formats in order for the exporter to extract and convert the condition correcfly. 
Cuirently, thect are three formats that are supported by the exporter, whidi are illustrated 
S below. Each variable defined in the process is generated to a Java backing class. This class 
contains the getter and setter methods to allow users to manipulate the data of that variable. 

Condition pattern 1 has the following format: 

getVariableNaxne ( ) . getPar tName ( ) =- "literal string* 

The condition compares a part of a variable to a literal string on the right 
10 variabieName is the name of the variable involved in the condition evaluation. This variable 
is defined in the process. PartName is the name of the part defined in the specified variable. It 
is of string type. This part must exist in the message type defined for the variable. The sign 
== defines the evaluation operation. The sign i = is also supported in this mapping. The literal 
string must be surrounded by quotations. 

15 In the preferred embodiment* an example of the translation of the above condition 

pattern is the following: 

bpws : getContainerData { ' VariabieName ' , ' PartName ' ) == * literal 

string • 

The above XPath condition uses a BPEL built-in function, 
20 bpws : getContainerData { ) , to extract data from a variable. Then the condition is evaluated 
by comparing the result to the literal string. 

Condition pattern 2 has the following format- 

get VariabieName ( ) . getPartName ( ) == integer 

The condition compares a part of a variable to integer on the right VariabieName 
25 is the name of the variable involved in the condition evaluation. This variable is defined in 
the process. PartName is the name of the part defined in the specified variable. It is of 
integer type. This part exists in the message type defined for the variable. The sign 



CA9-2003-0070 



-55- 



CA 02443447 2003-09-30 

defines the evaluation operation. Other symbols such as ! <, >= and <= are also supported 
in this mapping. 

In the preferred embodiment, an example of the translation of the second condition 
pattern is the following: 

ifpwe : getContainerOata ( ' VarlableName ' , ' PaurtName ' ) == integer 

The above XPath condition uses a BPEL built-in function, 
bpws :getcontainerData < ) , to extract data from a variable. Then the condition is evaluated 
by comparing the result to the integer. 

Condition pattern 3 has the following format: 

getVariablelName ( ) , getPartlNaiae ( ) == 
gekVariable2Name ( ] . get Part 2Mfame ( ) 

The condition compares a part of a variable to a part of another variable. The 
variable parts are of type integer or string. The source and target variable pans are of the 
same type. variableiName and variabi€2Name arc the names of the variables involved in 
the condition evaluation. These variables are defined in the process. PartiName and 
Part2Name are the names of the part defined in the specified variable. This part exists in the 
message type defined for the variable. The sign == defines the evaluation operation. Other 
symbols are also supported depending on the type. If both sides are of string type, ! » is 
supported If both are of integer type, symbols such as i =, >, <, >= and <= are also 
supported 

In the preferred embodiment, an example of the translation of the third condition 
pattern is the following: 

bpws : getContainerData < ' VariableiName ' , ' PartlName ' ) == 
bpws : getContainerData ( ' Var iable2Na3ne ' , ' Part2Name ' ) 

The above XPalh condition uses a BPEL built-in function, 
bpws:getContainerDataO» to extract data from variables. Then the condition is evaluated by 
comparing the results. 
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As may be seen firom the above description, in the piefened embodiment 
conversion is supported between a graphical representation supporting Java and a structural 
text-based representation supporting XPadi. 

As the preferred embodiment of the present invention has been described in detail 
by way of example, it will be apparent to those skilled in the art that variations and 
modifications may be made without departing from the invention. The invention includes all 
such variations and modifications as fall within the scope of the appended claims. 



CA9-2003-0070 



-57- 



CA 02443447 2003-09-30 



WHAT IS CLAIMED IS: 

1 . A computer program product for converting between graphical and structural text- 
based representations of business processes, the computer program product 
comprising a computer usable medium having computer readable program 
code means embodied in said medium, and comprising 

computer readable program code means for storing and maintaining a set 
of features identifiable in graphical business process representations, 
each feature in the set of features having an associated pattern mq>ping 
defined relative lo structural text-based representations, 

computer readable program code means for identifying portions of an 
initial graphical representation as matching features in the set of features, 

computer readable program code means for generating structural text- 
based representations of the identified portions of the initial graphical 
representation by applying the pattern mappings associated with the 
matching features to die identified pordons of the graph-based 
representation, 

computer readable program code means for identifying portions of an 
initial structural text-based representation of a business process as 
corresponding to pattern m^pings associated widi features in the set of 
features, and 

computer readable program code means for generating graphical 
representations of the identified portions of the initial structural text- 
based representation by reference to the features associated with the 
pattern mappings corresponding to the identified portions of the initial 
structural text-based representation. 

2. The computer program product of claim 1 , in which the set of identifiable features 
comprises features selected from: synchronous and asynchronous processes, 
request/response activities, one-way activities, empty nodes, blocks, iterations. 
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receive events, compensation, correlation, variables, fault handling and 
transition conditions. 

3. The computer program product of claim 2, in which the set of identifiable features 
and the associated pattern mappings, comprises feature and pattern mapping 
pairs selected from the following set of pairs: 

i. feature: synchronous/asynchronous processes; pattern mapping: a 
synchronous process representation comprises a <receive> activity as 
its input interface, and a <reply> activity as its ouq[>ut interface; an 
asynchronous process representation comprises a <receive> activity as 
its input interface, and an <invoke> activity as its output interface; 

iL feature: request/response activity; pattern mapping: an <invoke> 
activity with attributes inputContainer and outputContainer to specify 
input and output containers assigned to the activity; 

iii. feature: one-way activity; pattern mapping: an <dnvoke> activity, 
with attribute inputContainer and no outputContainer; 

iv. feature: empty node; pattern mapping: an <^pty> activity defined by 
a naming convention including node name; 

V, feature: block; pattern mapping: a <scope> activity with two <empty> 
activities nested within the <scope> activity to represent the input and 
output nodes in the block; 

vi. feature: iteration; pattern mapping: a <while> activity having an 
attribute condition equivalent to the loop condition in the loop node of 
the iteration; two <empry> activities nested within the <while> activity 
to represent input and output nodes in the loop body of the iteration; 

vii. feature: receive event; pattern mapping: a <pick> activity containing 
<onMessage> structures to define events accepted by the <pick> 
activity, corresponding to events defined in the receive event; 
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viii. feature: compensation; pattern mapping: a <a2ompensationHandler> 
structure comprising an activity within the structure to compensate an 
execution failure; 

ix. feature: correlation; pattern mapping: a <corrclation> element having a 
correlation ID defined and referenced by a <correlationSet> element; 
the <correlation> element being nested within a <receive> activity 
representing an input node, and within all <pick> activities 
corresponding to one or more receive event nodes; 

X. feature: variables; pattern mapping: containers; 

xi. feature; fault handling; pattern mapping: a <catch> structure 

containing elements in a fault path if the fault is only thrown once; 
where the fault is capable of being repeatedly caught and thrown then 

(a) if thrown intwnally: a <Arow> activity; or 

(b) if thrown externally: a <reply> activity; and 

xiL feature: transition condition; pattern mapping: an attribute in a 
<source> element of a <link> element representing the transition; 

4. The computer program product of claim 2, in which the computer readable 

program code means for generating stmctural text-based representations of the 
identified portions of the initial grq}h-based rq}resentation further comprises 
means for converting Java code referenced in the initial graphical 
representation to XPath code in the generated structural text4)ased 
representation. 

5. The compute program product of claim 4, in which the means for converting Java 

code to XPath code comprises means for converting Java snippet nodes, and 
Java assignment and condition expressions. 

6. The compute program product of claim 5, in which the initial graphical 

representation is compatible with the Wdj Sphere™ Studio Application 
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Developer bitegration Edition platfonn and the generated structural text-based 
representation is compatible with the Business Process Execution Language 
for Web Services platform. 

7. An import and export tool for exporting from graphical representations of 

business processes to structural text-based representations and for importing 
from structural text-based representations of business processes to graphical 
representations, the import and export tool comprising: 

storage and maintenance code for inplementing die storage and 
maintenance of a set of features identifiable in graphical business 
process representations, each feature in tfie set of features having an 
associated pattern mapping defined relative to structural text-based 
representations, 

graph identification code for identifying portions of an initial graphical 
representation as matching features in the set of features, 

export generation code for generating structural text-based 
representations of the identified portions of the initial graphical 
representation by applying the pattern mappings associated with the 
matching features to the identified portions of tlie graph-based 
representation, 

import identification code for identifying portions of an initial structural 
text-based representation of a business process as corresponding to 
pattern mappings associated with features in the set of features, and 

import generation code for generating gr^hical representations of the 
identified portions of the initial structural text-based representation by 
reference to the features associated with the pattern mappings 
corresponding to the identified portions of the initial structural text- 
based representation. 
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8. The import and export tool of claim 7, in which the set of identifiable features and 
the associated pattern mappings, comprises feature and pattern mapping pairs 
selected from the following set of pairs: 

i. feature: synchronous/asynchronous processes; pattern mapping: a 
synchronous process representation comprises a <receive> activity as 
its input interface, and a <reply> activity as its output interface; an 
asynchronous process representation comprises a <receive> activity as 
its input interface, and an <invoke> activity as its output interface; 

ii. feature: request/response activity; pattern mapping: an<invokc> 
activity with attributes inputContainer and outputContainer to specify 
input and ou^ut containers assigned to the activity; 

iii. feature: one-way activity; pattern mapping: an <invoke> activity, 
with attribute inputContainer and no outputContainer, 

iv. feature: empty node; pattern mapping: an <empty> activity defmed by 
a naming convention including node name; 

V. feature: block; pattern mapping: a <scope> activity with two <empty> 
activities nested within the <scope> activity to represent the input and 
output nodes in the block; 

vi. feature: iteration; pattern mapping: a <while> activity having an 
attribute condition equivalent to the loop condition in the loop node of 
the iteration; two <empty> activities nested within the <while> activity 
to represent input and output nodes in the loop body of the iteration; 

vii. feature: receive event; pattern mapping: a <pick> activity containing 
<onMe5sage> structures to define events accepted by the <pick> 
activity, corresponding to events defined in the receive event; 

viii. feature: compensation; pattern mapping: a <compensationHandler> 
structure comprising an activity within the structure to compensate an 
execution failure; 
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ix. feature: correlation; pattern mapping: a <correlation> element having a 
correlation ID defined and referenced by a <conre]ationSet> element; 
the <ccHiielation> element being nested within a <i:eceive> activity 
representing an input node, and within all <pick> activities 
corresponding to one or more receive event nodes; 

X. feature: variables; pattern mapping: containers; 

xi. feature: fault handling; pattern mapping: a <catch> structure 
containing elements in a fault path if the fault is only thrown once; 
where the fault is capable of being repeatedly caught and thrown thm 

(a) if thrown internally: a <throw> acdvity; or 

(b) if thrown externally: a <reply> activity; and 

xii. feature: transition condition; pattem mapping: an attribute in a 
<source> element of a <link> element representing the transition; 

9. The import and export tool of claim 7, in which the export generation code 

comprises conv^ion code for converting Java code referenced in the initial 
graphical representation to XPath code in the generated structural text-based 
representation. 

10. A computer program product for converting from a graphical to a structural text- 

based representation of business processes, the computer program product 
comprising a computer usable medium having computer readable program 
code means embodied in said medium, and comprising 

computer readable program code means for storing and maintaining a set 
of features identifiable in graphical business process r^resentations, 
each feature in the set of features having an associated pattem mapping 
defined relative to structural text-based representations, 
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computer readable program code means for identifying portions of an 
initial graphical representation as matching features in the set of features, 
and 

computer readable program code means for generating structural text- 
based representations of the identified portions of the initial graphical 
representation by applying die pattern mappings associated with the 
matching features to the identified portions of the graph-based 
representation. 

1 1 . The computer program product of claim 10» in which the computer readable 

program code means for generating structural text-based representations of the 
identified poitions of die initial grai^-based represoitaiion further comprises 
means for extracting prop^es from grs^hical elements in the identified 
portions of the initial gr^h-based representation and defining conespooding 
attributes for elements in the generated structural text based representations. 

12. The conq)uter program product of claim 1 1, in which the set of identifiable 

features comprises features selected from: synchronous and asynchronous 
processes, request/response activities, one-way activities, empty nodes, blocks, 
iterations, receive events, compensation, correlation, variables, fault handling 
and transition conditions. 

13. The computer program product of claim 10, in which the set of identifiable 

features and the associated pattern mappings, comprises feature and pattern 
mapping pairs selected from the following set of pairs: 

i. feature: synchronous/asynchronous processes; pattern mapping: a 
synchronous process representation comprises a <receive> activity as 
its input interface, and a <reply> activity as its output interface; an 
asynchronous process representation comprises a <:receive> activity as 
its input interface, and an <invoke> activity as its ou^ut int^ace; 
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ii. feature: request/response activity; pattern mapping: an <invoke> 
activity with attributes inputContainer and outputContainer to specify 
input and ou^ut containers assigned to die activity; 

iii. feature: one-way activity; pattern mapping: an <invoke> activity, 
with attribute inputContainer and no outputContainer, 

iv. feature: empty node; pattern mapping: an <empty> activity defined by 
a naming convendon including node name; 

V. feature: block; pattern nnapping: a <scope> activity with two <empty> 
activities nested within the <scope> activity to represent the input and 
ou^ut nodes in the block; 

vi. feature: iteration; pattern mapping: a <while> activity having an 

attribute condition equivalent to the loop condition in the loop node of 
the iteration; two <en5)ty> activities nested widiin the <while> activity 
to represent input and output nodes in the loop body of the iteration; 

viL feature: receive event; pattern mapping: a <pick> activity containing 
<onMessage> structures to define events accepted by the <pick> 
activity, corresponding to events defined in the recdve event; 

viii. feature: compensation; pattern mapping: a <con4)ensationHandler> 
structore comprising an activity within the structiue to compensate an 
execution failure; 

ix. feature: correlation; pattern mapping: a <correlation> element having a 
correlation ID defmed and referenced by a <correlationSet> element; 
the <correlation> element being nested within a <receive> activity 
representing an input node, and within all <pick> activities 
corresponding to one or more receive event nodes; 

X. feature: variables; pattern mapping: containers; 
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xi. feature: fault handling; pattern mapping: a <catch> structure 

containing elements in a fault path if the fault is only thrown once; 
where the fault is capable of being repeatedly caught and thrown then 

(a) if thrown internally: a <throw> activity; or 

(b) if thrown externally: a <reply> activity; and 

xiL feature: transition condition; pattern mapping: an attribute in a 
<source> clement of a <link> element representing the transition; 

14. The computer program product of claim 12, in which the computer readable 

program code means for generating structural text-based representatioDS of the 
identified portions of the initial graph-based representation further comprises 
means for converting Java code referenced in the initial gr^hical 
representation to XPath code in the generated structural text-based 
representation. 

13. The computer program product of claim 14, in whidi die means for converting 
Java code to XPath code comprises means for converting Java snippet nodes, 
and Java assignment and condition expressions. 

16. The computer program product of claim 15, in which the initial graphical 

representation is compatible with the Web Sphere^^ Studio Application 
Developer hitegration Edition platform and the generated structural text-based 
representation is compatible with the Business Process Execution Language 
for Web Services platform. 

17. An export CdoI for exporting from graphical representations of business processes 

to stmctural text-based representations, the export tool comprising: 

storage and maintenance code for implementing the storage and 
maintenance of a set of features identifiable in graphical business 
process representations, each feature in the set of features having an 
associated pattern mapping defined relative to structural text-based 
r^resentations, 
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graph identification code for identifying poitions of an initial graphical 
representation as matching features in (he set of features, and 

export generation code for generating structural text-based 
representations of the identified portions of the initial graphical 
representation by applying die pattern mappings associated with the 
matching features to the identified pordons of the graph-based 
representation. 

1 8. The export tool of claim 1 7, in which the set of identifiable features con^rises 

features selected from: synchronous and asynchronous processes, 
request/response activities, one-way activities* empty nodes, blocks, iterations, 
receive events, compensation, oonneiation, variables, £ault handling and 
transition conditions. 

19. The export tool of claim 1 8, in which the set of identifiable features and the 

associated pattern m^pings, comprises feature and pattern mapping pairs 
selected from the following set of pairs: 

i. feature: synchronous/asynchronous processes; pattern mapping: a 
synchronous process representation comprises a <recdv^ activity as 
its input interface, and a <reply> activity as its ou^ut interface; an 
asynchronous process representation comprises a <receive> activity as 
its input interface, and an <invoke> activity as its output int^ace; 

ii. feature: request/response activity; pattern moping: an<invoke> 
activity with attributes inputContainer and oa^utContain^ to specify 
input and output containers assigned to the activity; 

iii. feature: one-way activity; pattern mapping: an <invoke> activity, 
with attribute inputContainer and no outputContainer; 

iv. feature: empty node; pattern mapping: an <empty> activity defined by 
a naming convention including node name; 
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V. feature: block; pattern mapping: a <scope> activity with two <empty> 
activities nested within the <scope> activity to represent the input and 
output nodes in the block; 

vi. feature: iteration; pattern mapping: a <whiie> activity having an 
attribute condition equivalent to the loop condition in the loop node of 
the iteration; two <empty> activities nested within the <whi]e> activity 
to represent input and output nodes in the loop body of the iteration; 

vii. feature: receive event; pattern mapping: a <pick> activity containing 
<onMessage> structures to define events accepted by the <pick> 
activity, corresponding to events defined in the receive event; 

viii. feature: compensation; pattern mapping: a <compensationHandler> 
structure comprising an activity within the structure to compensate an 
execution failure; 

ix. feature: correlation; pattern mapping: a <correlation> element having a 
correlation ID defined and referenced by a <correlationSet> element; 
the <correlation> element being nested within a <receive> activity 
representing an input node, and within all <pick> activities 
corresponding to one or more receive event nodes; 

X. feature: variables; pattern mapping: containers; 

xi. feature: fault handling; pattern mapping: a <catch> structure 

containing elements in a fault path if the fault is only thrown once; 
where the fault is capable of being repeatedly caught and thrown then 

(a) if thrown internally: a <throw> activity; or 

(b) if thrown externally: a <reply> activity; and 

xii. feature: transition condition; pattern mapping: an attribute in a 
<source> element of a <link> element representing the transition; 
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20. The export tool of claim 1 7, in which the export generation code comprises 

conversion code for converting Java code referenced in the initial graphical 
representation to XPath code in the generated structural text-based 
representation- 

21 . An import tool for importing from structural text-based representations of 

business processes to graphical representations, the import tool comprising: 

ston^e and maintenance code for implementing the storage and 
maintenance of a set of features i^tifiable in gnq>hical business 
process representations, each feature in the set of features having an 
associated pattmi mapping defined relative to structural text-based 
Fqxresentations, 

import identification code for identifying portions of an initial structural 
text-based representation of a business process as corresponding to 
pattern mappings associated with features in the set of features, and 

import generation code for generating graphical representations of the 
identified portions of the initial structural text-based representation by 
reference to the features associated with the pattern mappings 
corresponding to the identified portions of the initial structural text- 
based representation. 

22. The import tool of claim 21, in which the set of identifiable features and the 

associated pattern mappings, comprises feature and pattern making pairs 
selected from the following set of pairs: 

i. feature: synchronous/asynchronous processes; pattern mapping: a 
synchronous process representation comprises a <receive> activity as 
its input interface, and a <reply> activity as its output interface; an 
asynchronous process representation comprises a <receive> activity as 
its input interface, and an <invoke> activity as its output interface; 
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ii. featuie: request/response activity; pattern mapping: an<invoke> 
activity with attributes inputContainer and outputContainer to specify 
input and output containers assigned to the activity; 

iii. feature: one-way activity; pattern mapping: an <invoke> activity, 
with attribute inputContainer and no outputContainer; 

iv. feature: empty node; pattern mapping: an <empty> activity defined by 
a nanfiing convention including node name; 

V. feature: block; pattern mapping: a <scope> activity with two <empty> 
activities nested within the <scope> activity to represent the input and 
ou^ut nodes in the block; 

vi. feature: iteration; pattern mapping: a <:while> activity having an 
attribute condition equivalent to the loop condition in the loop node of 
the iteration; two <emply> activities nested within the <while> activity 
to represent input and output nodes in the loop body of the iteration; 

vii. featuie: receive event; pattern niapping: a <piclc> activity containing 
<onMessage> structures to define events accepted by the <pick> 
activity, corresponding to events defined in flie recdve event; 

viii. feature: compensation; pattern mapping: a <compen$ationHandler> 
structure comprising an activity within the structure to compensate an 
execution failure; 

ix. feature: correlation; pattern mapping: a <con:elation> element having a 
correlation ID defined and referenced by a <correlationSet> element; 
the <:correlation> element being nested within a <xeceive> activity 
r^resenting an input node, and within all <pick> activities 
corresponding to one or more receive event nodes; 

X. feature: variables; pattern mapping: contains; 
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xi. feature: fault handling; pattern mapping: a <catch> structure 

containing elements in a fault path if the fault is only thrown once; 
where the fault is capable of being repeatedly caught and thrown dien 

(a) if thrown internally: a <throw> activity; or 

(b) if thrown externally: a <reply> activity; and 

xii* feature: transition condition; pattern miapping: an attribute in a 
<source> element of a <link> element representing the transition; 

23. A computer implemented niethod for converting from grsqphical to structural text- 

based representations of business processes, the method con4>rising the stq)s 
of: 

defining and maintaining a data rq)resentadon of a s^ of features 
identifiable in graphical business process representations, each feature in 
the set of features having an associated pattern mapping defined relative 
to structural text-based rq)resentations, 

identifying ponions of an initial graphical representation matching 
features in the set of features, and 

generating structural text-based representations of the identified portions 
of the initial graphical representation by applying the pattern mappings 
associated witii the matching features to the identified portions of the 
gr^h-based representation. 

24. The method of claim 23, in which the set of identifiable features comprises 

features selected from: synchronous and asynchronous processes, 
request/response activities, one-way activities, empty nodes, blocks, iterations, 
receive events, compensation, correlation, variables, fault handling and 
transition conditions. 
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25. The method of claim 24, in which the set of identifiable features and the 

associated pattern mappings, comprises feature and pattern ms^ping pairs 
selected from the following set of pairs: 

i. feature: synchronous/asynchronous processes; pattern mapping: a 
synchronous process representation comprises a <receive> activity as 
its input interface, and a <reply> activity as its output interface; an 
asynchronous process representation comprises a <receive> activity as 
its input interface, and an <invoke> activity as its output interface; 

ii. feature: request/response activity; pattern mapping: an<invok^ 
activity with attributes inputContainer and outputContainer to specify 
input and output containers assigned to the activity; 

iii. feature: one-way activity; pattern mapping: an <invoke> activity, 
with attribute inputContainer and no outputContainer; 

iv. feature: empty node; pattm mi^ping: an <empty> activity defined by 
a naming convention including node name; 

v. feature: block; pattern moping: a <scope> activity with two <empty> 
activities nested within the <scope> activity to represent the input and 
output nodes in the block; 

vi. feature: iteration; pattern mapping: a <while> activitj' having an 
attribute condition equivalent to the loop condition in the loop node of 
die iteration; two <empty> activities nested within the <:while> activity 
to represent input and output nodes in the loop body of the iteration; 

vii. feature: receive event; pattern mapping: a <pick> activity containing 
<onMessage> structures to define events accepted by die <$ick> 
activity, corresponding to events defined in the receive event; 

viiL feature: compensation; pattern mapping: a <compensationHandler> 
structure comprising an activity within the structure to compensate an 
execution failure; 
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ix. feature: correlation; pattern mapping: a <correlation> element having a 
correlation ID deiined and referenced by a <correlationSet> element; 
the <correlation> element being nested within a <receive> activity 
representing an input node, and within all <pick> activities 
corresponding to one or more receive event nodes; 

X. feature: variables; pattern mapping: containers; 

xi. feature: fault handling; pattern mapping: a <catch> structure 

containing elements in a fault path if the fault is only thrown once; 
where die fault is capable of being rq)eaiedly caught and thrown then 

(a) if thrown internally: a <throw> activity; or 

(b) if thrown ext^nally: a <reply> activity; and 

xii. feature: transition condition; pattern mailing: an attribute in a 
<source> elonent of a <link> element rq>resentiiig die transition; 

26. The method of claim 24, in which the step of generating structural text-based 

representations of the identified portions of the initial graph-based 
representation further comprises the steps of converting Java code referenced 
in the initial graphical representation to XPath code in the generated structural 
text-based representation. 

27. The method of claim 26, in which the steps of converting Java code to XPath code 

comprises the steps of converting Java snippet nodes, and Java assignment 
and condition expressions. 

28. The method of claim 27, in which the initial grapliical representation is 

compatible with die Web Sphere™ Studio Application Developer Integration 
Edition platform and the generated structural text-based representation is 
compatible with the Business Process Execution Language for Web Services 
platform. 
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29. A computer program product comprising a computer-readable signal-bearing 

medium, the said medium comprising means for accomplishing the method of 
claim 23. 

30. The computer program product of claim 29 in which the medium is a recordable 

data storage medium. 

3 1 . The compute program product of claim 29 in which the medium is a modulated 

carrier signal. 

32. The computer program product of claim 31 in which the signal is a transmission 

over a network. 

33. The computer program product of claim 32 claim in which network is the Internet 

34. A computer program product comprising a computer-readable signal-bearing 

transmission over a network, the said product comprising means for 
accomplishing the method of claim 25. 
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Figure 16 
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